กรณีศึกษา & ผลงานการแก้ปัญหาระบบฐานข้อมูล

รวมประสบการณ์จากงานภาคสนาม เพื่ออธิบายสถานการณ์ ผลกระทบ วิธีหาสาเหตุ การแก้ไข และผลลัพธ์ที่เกิดขึ้นอย่างเป็นขั้นตอน

หน้าแรก > กรณีศึกษา

เริ่มจาก Case ที่สะท้อนอาการ วิธีวิเคราะห์ การแก้ไข และผลลัพธ์ได้ชัด ทั้ง Oracle, Oracle RAC และ SQL Server

Oracle Performance · AWR Compare

ระบบ CRM ช้า เพราะ Transaction กำลังรอ Lock กันเอง

AWR (รายงาน Performance ของ Oracle) พบว่า 61.98% ของเวลาฐานข้อมูลหมดไปกับการรอ Lock ไม่ใช่การประมวลผล ทีมจึงตามรอยจนพบจุดที่ทำให้ผู้ใช้ต้องรอ

ดู Case 10 → Cross-platform Tuning · แก้ไขแล้ว

Epicor ERP และ SQL Server: ปัญหาไม่ได้อยู่ที่ Database เพียงชั้นเดียว

วิเคราะห์ตั้งแต่ Business Process, Application Query จนถึง Database Engine แสดงประสบการณ์จูนฐานข้อมูลโดยไม่ยึดติดกับยี่ห้อ

ดู Case 1 → Oracle RAC · Commit Performance

RAC รับ Transaction พอ ๆ กัน แต่ฝั่งหนึ่งรอ COMMIT นานกว่า 2.5 เท่า

จำนวนงานเกือบเท่ากัน แต่ Redo ต่อ Transaction และ log file sync ต่างกันมาก AWR จึงพาทีมตามรอย Commit path แทนการโทษ Load Balancing

อ่าน Case 13 ฉบับเต็ม → Oracle Incident · ORA-01653

Oracle ฟ้องพื้นที่ไม่พอ แต่ Disk ยังไม่เต็ม

Datafile เดิมโตถึงเพดานแล้ว Oracle จึงใช้พื้นที่ว่างบน Disk ต่อไม่ได้ ทีมเพิ่ม Datafile ใหม่ให้ Tablespace และระบบกลับมาบันทึก Transaction ได้

อ่าน Case 4 ฉบับเต็ม →
Case จากประสบการณ์ทำงานจริง: แต่ละเรื่องสรุปอาการ ผลกระทบ วิธีวิเคราะห์ สิ่งที่ทีมดำเนินการ และผลลัพธ์หลังแก้ไข — ตัวเลขแสดงเฉพาะข้อมูลที่เหมาะกับการเผยแพร่ และปกปิดชื่อองค์กร ระบบ และ Object ภายในของลูกค้า
⚙️ Performance, Application & Database Engineering 11

สถานการณ์: Epicor ERP ช้าลงเมื่อข้อมูลและงานค้างสะสม

ทีมวิเคราะห์ระบบแบบ End-to-End ตั้งแต่ Business Process, Application Query จนถึง SQL Server 2016 เพื่อหาคอขวดจริง แทนการมองว่า Database หรือ Hardware เป็นสาเหตุเพียงอย่างเดียว

⏱️
อาการและผลกระทบ
Data Purging ทำให้เร็วขึ้นชั่วคราว แต่อาการกลับมาเมื่อข้อมูลสะสม

การ Purge ช่วยบรรเทาอาการได้ช่วงหนึ่ง แต่เมื่อข้อมูลและ Active Records เพิ่มขึ้น ระบบกลับมาช้าอีกครั้ง จึงต้องหาสาเหตุที่เชื่อมโยงทั้งขั้นตอนทำงานและคำสั่ง SQL

🔍
การวิเคราะห์
พบสามชั้นที่ต้องแก้ร่วมกัน

ทีมเชื่อมอาการกับสามส่วนที่เกี่ยวข้อง แทนการปรับ Database Parameter แบบแยกส่วน:

Business Logic
ข้ามขั้นตอนปิด Job
ตรวจขั้นตอน Job Closing และ Active Records ที่ทำให้ปริมาณงานค้างสะสม
Application Query
Scalar UDF ฝังในคิวรี
ตรวจ Scalar User Defined Function ใน Query Path ซึ่งอาจเพิ่มงานแบบ Row-by-Row
Database Engine
SQL Server 2016 และ Scalar UDF
ประเมินพฤติกรรม Optimizer, Index และข้อจำกัดของ Scalar UDF บน SQL Server 2016 ร่วมกับ Workload จริง
🛠️
สิ่งที่ทีมดำเนินการ
ปรับ Business Process, Query และ Database Engine ให้ทำงานสอดคล้องกัน

การแก้ปัญหาครอบคลุมจุดที่พบจากการวิเคราะห์:

  • Business Process: จัดการขั้นตอนปิด Job และลด Active Records ที่ไม่จำเป็น
  • Application Query: ปรับ Query Path ที่เกี่ยวข้องกับ Scalar UDF และการเข้าถึงข้อมูล
  • Database Engine: ปรับแนวทางให้เหมาะกับพฤติกรรมของ SQL Server 2016 และ Workload ของ ERP
💡
ผลลัพธ์
ระบบตอบสนองดีขึ้นจนผู้ใช้งานยอมรับได้
💡

Database Performance Tuning ที่ไม่ยึดติดกับยี่ห้อ

หลังปรับจุดที่เกี่ยวข้องทั้ง Business Process, Application Code และ Database Engine ประสิทธิภาพของ Epicor ERP ดีขึ้นจนตอบโจทย์การใช้งาน Case นี้แสดงว่าทีมสามารถใช้หลัก Performance Engineering กับฐานข้อมูลหลายแพลตฟอร์ม ไม่จำกัดเฉพาะ Oracle

อ่าน Case 1 และกรอบวิเคราะห์ Cross-platform →

สถานการณ์: Oracle 12c และ GlassFish หน่วงเมื่อมีผู้ใช้พร้อมกัน

ทีมตรวจเส้นทางการทำงานตั้งแต่ Application, GlassFish Connection Pool, Network จนถึง Oracle Database เพื่อแยกปัญหา Connection Churn ออกจากข้อจำกัดด้านทรัพยากร

🚨
อาการและผลกระทบ
ระบบหน่วงชัดเจนเมื่อจำนวนผู้ใช้พร้อมกันเพิ่มขึ้น

แอปพลิเคชันแบบ 3-Tier ตอบสนองช้าลงเมื่อมี Concurrent Users มากขึ้น ส่งผลให้การทำงานผ่านหน้าจอและการเชื่อมต่อฐานข้อมูลติดขัด

❌
สิ่งที่ลองแล้ว
การเพิ่ม RAM ถูกกล่าวว่าไม่ทำให้อาการหาย

การเพิ่มทรัพยากรไม่ได้ทำให้อาการหาย เพราะคอขวดไม่ได้อยู่ที่ปริมาณ RAM เพียงอย่างเดียว ทีมจึงเปลี่ยนจากการเพิ่ม Hardware มาเป็นการวิเคราะห์ Connection Lifecycle

🔍
การวิเคราะห์
Connection Churn และ Logon Overhead เป็นจุดสำคัญของปัญหา

การเปิด–ปิด Database Connection บ่อยทำให้เกิด Logon Overhead และเพิ่มภาระ Process ทีมจึงตรวจข้อมูลสองฝั่งควบคู่กัน:

  • GlassFish: pool configuration, pool statistics และ connection lifecycle
  • Oracle: logon rate, session/process count, AWR/ASH และ listener evidence ในช่วงเกิดอาการ
✅
สิ่งที่ทีมดำเนินการ
ปรับ Connection Pool และ Capacity ให้สัมพันธ์กับ Workload

ทีมปรับพฤติกรรมการใช้ Connection และค่าที่เกี่ยวข้องโดยอ้างอิง Workload จริง:

  • Connection Pool: ปรับขนาด Pool, Connection Lifecycle และการนำ Connection กลับมาใช้ซ้ำ
  • Oracle Capacity: ตรวจและปรับ PROCESSES กับ SESSIONS ให้รองรับจำนวน Connection อย่างเหมาะสม
  • End-to-End: ตรวจ Response Time, Logon Rate, CPU และ Error ร่วมกันทั้ง Application และ Database
💡
ผลลัพธ์
รองรับผู้ใช้พร้อมกันได้ดีขึ้นโดยไม่แก้ปัญหาด้วย Hardware อย่างเดียว
💡

ผลลัพธ์จากการวิเคราะห์แบบ End-to-End

หลังปรับ Connection Pool และค่าที่เกี่ยวข้อง ระบบตอบสนองดีขึ้นเมื่อมีผู้ใช้พร้อมกัน และลดภาระที่เกิดจากการสร้าง Connection ซ้ำโดยไม่จำเป็น

สถานการณ์: Oracle 9i ประมวลผล Batch ช้าแม้เพิ่ม RAM แล้ว

ทีมวิเคราะห์การใช้ Memory ทั้ง Oracle และ Operating System แยก SGA, PGA, Buffer Cache, Workarea และ Physical Reads เพื่อให้ทรัพยากรที่มีอยู่ถูกใช้อย่างเหมาะสมกับ Workload

🚨
อาการและผลกระทบ
Batch ใช้เวลานานและระบบมีอาการค้าง แม้เครื่องมี RAM เพิ่มขึ้น

การเพิ่ม Physical RAM ไม่ทำให้ Oracle ใช้ Memory เพิ่มโดยอัตโนมัติ เมื่อค่า SGA/PGA และรูปแบบ Workload ยังเหมือนเดิม ระบบจึงยังประมวลผลช้า

🔍
การวิเคราะห์
การจัดสรร SGA/PGA ไม่สอดคล้องกับ Workload ของระบบ

การเพิ่ม Physical RAM จะไม่ช่วยโดยอัตโนมัติหาก Oracle ยังใช้ค่า memory target เดิม แต่การพิสูจน์ว่า memory เป็นคอขวดต้องมีข้อมูลอย่างน้อย:

  • Oracle memory: ค่า SGA/PGA components, cache advice, workarea statistics และ physical reads ในช่วงเกิดอาการ
  • Operating System: available memory, paging/swapping และ process memory เพื่อแยก database pressure ออกจาก OS pressure
🛠️
สิ่งที่ทีมดำเนินการ
ใช้ Advisor และ Baseline แทนสูตรแบ่ง Memory แบบตายตัว

การปรับ Instance Tuning ควรเริ่มจาก workload และความสามารถของ Oracle version ไม่ใช่ใช้ cache hit ratio หรือสูตรรวม memory เพียงค่าเดียว:

  • ตรวจ Baseline: response time, DB time, physical reads และ OS paging ก่อนเปลี่ยนค่า
  • ทดสอบ Memory: เปลี่ยน SGA/PGA ทีละขั้น ตรวจผลต่อ workload และรักษา OS headroom โดยคำนึงว่า PGA target ไม่ใช่ hard limit
📈
ผลลัพธ์
Batch ทำงานได้เร็วขึ้นและอาการค้างลดลง

หลังปรับ SGA/PGA และองค์ประกอบ Memory ให้เหมาะกับ Workload ระบบใช้ทรัพยากรเดิมได้มีประสิทธิภาพขึ้น งานประมวลผลเสร็จเร็วขึ้นและผู้ใช้กลับมาทำงานได้ตามปกติ

สถานการณ์: งาน Batch ใช้เวลานานและต้องแยกว่า CPU ไม่พอ หรือ Oracle กำลังรอทรัพยากร

AWR จากระบบจริงยืนยัน Wait Event สำคัญสองรายการในคนละช่วงรายงาน ได้แก่ resmgr:cpu quantum 22.38% ของ DB Time และ PX qref latch 12.37% ของ DB Time ตัวเลขนี้ช่วยชี้จุดตรวจสอบ แต่ยังไม่พิสูจน์ว่า Scheduler, SQL Hint หรือสาเหตุใดสาเหตุหนึ่งเป็น Root Cause เพียงข้อเดียว

🚨
หลักฐานที่ยืนยันแล้ว
AWR แสดง Resource Manager wait และ Parallel Execution wait ในช่วงงาน Batch
  • resmgr:cpu quantum: 5,408,083 waits, 28,320 วินาที และ 22.38% ของ DB Time ใน AWR ช่วงประมาณ 594 นาที
  • PX qref latch: AWR อีกช่วงหนึ่งบันทึก 33,385,785 waits, 2,775 วินาที และ 12.37% ของ DB Time
  • ขอบเขตตัวเลข: เปอร์เซ็นต์เป็นสัดส่วนต่อ DB Time ของแต่ละ AWR ไม่ใช่เปอร์เซ็นต์ Downtime และไม่ควรนำสองช่วงมาบวกกัน
🔍
วิเคราะห์สาเหตุ — แยกข้อเท็จจริงจากสมมติฐาน
AWR ยืนยันสิ่งที่รอ แต่ยังต้องเชื่อมกับงานและ Configuration ในเวลาเดียวกัน
ยืนยันแล้ว
resmgr:cpu quantum คือการรอ CPU quantum ที่ Resource Manager จัดสรร
ค่าใน AWR พิสูจน์ว่ามี CPU throttling ผ่าน Oracle Resource Manager ในช่วงนั้น แต่ยังไม่ระบุว่า Consumer Group หรือ Resource Plan ใดควรแก้โดยไม่ตรวจ Configuration เพิ่ม
ยืนยันแล้ว
PX qref latch เกี่ยวข้องกับ queue buffer ของ Parallel Execution
Wait Event ยืนยัน contention ในกลไก Parallel Execution แต่ยังไม่พิสูจน์ว่า SQL Hint หรือ Degree of Parallelism ค่าใดเป็นต้นเหตุโดยตรง
ต้องพิสูจน์เพิ่ม
Scheduler overlap, Parallel Hint และ Stale Statistics
เป็นสมมติฐานจากบันทึกการวิเคราะห์เดิม ต้องเทียบ Job history, SQL text, Execution Plan, Object Statistics และช่วงเวลาเดียวกับ AWR ก่อนกล่าวเป็น Root Cause
🛠️
แนวทางตรวจสอบอย่างปลอดภัย
ตรวจ Timeline, Resource Plan และ Parallel SQL ก่อนเปลี่ยนค่า
  • เชื่อม Timeline: เทียบเวลา Batch, Scheduler/maintenance job และ Top SQL ให้เป็นช่วงเดียวกัน
  • ตรวจ Resource Manager: ดู Resource Plan, Consumer Group และ CPU allocation ก่อนทดลองปรับ พร้อมเก็บ AWR ก่อน–หลัง
  • ทดสอบ Parallelism: ตรวจ SQL Monitor/Execution Plan และ Degree of Parallelism; ทดลองเฉพาะระบบทดสอบหรือช่วงควบคุม ไม่ถอด Hint แบบเหมารวม
  • วัดผล: เปรียบเทียบ Batch duration, DB Time, wait seconds, throughput และ CPU ของช่วงงานเดียวกัน
📊
ผลลัพธ์
งาน Batch เร็วขึ้น พร้อมกรอบอ่าน DB CPU และ DB Wait Time สำหรับ DBA/IT

สัดส่วน DB CPU และ DB wait time ช่วยจัดลำดับการตรวจสอบ แต่ต้องอ่านร่วมกับ Baseline, Workload และเวลาที่เกิดเหตุ ไม่ใช่เกณฑ์มาตรฐานที่ใช้ตัดสิน Root Cause หรือการเพิ่ม Hardware ได้ด้วยตัวมันเอง:

DB CPU
เมื่อ DB CPU เป็นสัดส่วนเด่น
ตรวจ Top SQL by CPU, Execution Plan, call rate และ OS CPU utilization ก่อนสรุปว่า SQL หรือจำนวน CPU เป็นคอขวด
DB Wait
เมื่อ DB Wait เป็นสัดส่วนเด่น
แยก Wait Class และ exact Wait Event แล้วเชื่อมกับ Session, SQL, Object และ Timeline; เปอร์เซ็นต์ Wait เพียงค่าเดียวไม่บอกวิธีแก้
Workload
ตีความด้วย Baseline ของระบบเดียวกัน
ไม่มีเส้นแบ่งตายตัวที่พิสูจน์ว่า Workload scalable หรือควรเพิ่ม CPU/RAC Node ต้องเทียบช่วงปกติกับช่วงมีปัญหาและวัดผลหลังเปลี่ยน
💡

ผลลัพธ์: งาน Batch กลับมาทำงานได้เร็วขึ้น

ทีมปรับ Resource Plan, Parallel Execution และงานที่ทำงานทับซ้อนกันตามจุดที่ AWR ชี้ ทำให้ภาระการรอทรัพยากรลดลงและ Batch เสร็จในเวลาที่ผู้ใช้งานต้องการ โดยไม่รีบแก้ด้วยการเพิ่ม Hardware เพียงอย่างเดียว

ผู้ใช้รู้สึกว่าระบบช้า แต่ยังไม่รู้ว่างานไปติดอยู่ตรงไหน

จากหน้าจอ Application (โปรแกรมที่ผู้ใช้ทำงานอยู่) เห็นเพียงว่าระบบตอบสนองช้ากว่าที่ควร ทีมจึงใช้ AWR (รายงานสรุปประสิทธิภาพที่ Oracle เก็บจากการทำงานจริง) เพื่อดูว่าฐานข้อมูลกำลังใช้ทรัพยากรไปกับงานส่วนใด

🚨
อาการที่ผู้ใช้พบ
ระบบตอบสนองช้า แต่ความช้ายังไม่ได้บอกว่าสาเหตุอยู่ที่ใด

ทีมเริ่มจากอาการที่ผู้ใช้สัมผัสได้ แล้วตรวจลงไปในฐานข้อมูลแทนการเดาว่าเป็นปัญหาจาก Application, Server หรือ Disk

AWR พบ Logical Reads (จำนวนครั้งที่ Oracle หยิบ Data Block หรือก้อนข้อมูลมาตรวจผ่านหน่วยความจำ) รวมประมาณ 707.23 ล้านครั้ง โดย Table (ตารางข้อมูล) รายการเดียวรับไป 628.87 ล้านครั้งหรือ 88.92% และอีก Partition (ส่วนย่อยของ Table) หนึ่งส่วนรับ 38.71 ล้านครั้งหรือ 5.47% สองจุดรวมกันเป็น 94.39% ของการอ่านทั้งหมด

แม้ Block จะอยู่ใน Memory แต่ Oracle ยังต้องค้นหา ตรวจ และประมวลผลทุกครั้ง การทำซ้ำหลายร้อยล้านครั้งจึงใช้ CPU และทรัพยากรภายในฐานข้อมูล ทำให้งานอื่นมีทรัพยากรเหลือน้อยลงและผู้ใช้อาจต้องรอนานขึ้น

SQL ถูกเรียกบ่อย × อ่านหลาย Block ต่อครั้ง = Logical Reads จำนวนมาก

ตัวเลขระดับ Segment จึงเป็นพิกัดว่า “งานกระจุกอยู่ที่ไหน” ไม่ใช่คำตอบทันทีว่า Disk, Table หรือ Index เป็นสาเหตุ

🔍
เส้นทางการวิเคราะห์
Table ไม่ได้อ่านตัวเอง ต้องตามต่อไปยัง SQL และ Execution Plan

ทีมเชื่อม Segment กับ SQL ordered by Gets/Reads แล้วตรวจ Execution Plan (แผนที่ Oracle ใช้ค้นข้อมูล), Predicate, Bind Value, จำนวน Execution และ Buffer Gets ต่อครั้ง เพื่อแยกว่า SQL ถูกเรียกถี่ อ่านกว้างเกินไป หรือเกิดทั้งสองอย่างพร้อมกัน

สำหรับ Table ที่แบ่ง Partition ทีมตรวจ PSTART/PSTOP เพื่อดูว่า Partition Pruning ตัดส่วนที่ไม่เกี่ยวข้องออกจริงหรือไม่ ก่อนพิจารณา Local Index, Global Index และวงจรชีวิตข้อมูล

🛠️
ทีมแก้อย่างไร
ปรับ Index, วิธีเข้าถึง Partition และการจัดการข้อมูลเก่า
  • ปรับ Index: เลือกโครงสร้างให้ตรงกับเงื่อนไขค้นหาของ SQL เพื่อลดการเปิดดูข้อมูลกว้างเกินไป
  • ปรับ Partition Access: ทำให้ Oracle เลือกอ่านเฉพาะส่วนของข้อมูลที่เกี่ยวข้องกับคำสั่ง
  • จัดการ Data Lifecycle: แยกวิธีดูแลข้อมูลเก่า เพื่อลดปริมาณข้อมูลที่งานประจำต้องค้นหา
💡
หลังดำเนินการ
ระบบตอบสนองดีขึ้นหลังจัดการจุดอ่านข้อมูลที่กระจุกตัว
💡

หลังแก้ Oracle ค้นข้อมูลตรงกับงานมากขึ้น

เมื่อปรับ Index, การเลือก Partition และขอบเขตข้อมูลที่ต้องดูแลแล้ว ระบบตอบสนองดีขึ้น และลดงานที่ไม่จำเป็นในจุดซึ่งเคยมีการอ่านกระจุกตัวสูง

อ่านเรื่องราวและรายละเอียดสำหรับ DBA/IT →

สถานการณ์: Parameter Snapshot มี PGA target ต่ำ และ Advisor ประเมินการจัดสรรเกินเป้าหมายหลายครั้ง

Parameter Snapshot พบ pga_aggregate_target 32 MiB, db_cache_size 144 MiB และ sga_max_size ประมาณ 441 MiB ขณะที่ PGA Target Advice แสดง Estimated Over-allocation หลายครั้ง ทีมจึงใช้ Advisor ร่วมกับ Workload เพื่อปรับ Workarea Memory อย่างเป็นขั้นตอน

🚨
หลักฐานที่ยืนยันแล้ว
PGA Target Advice ประเมิน Over-allocation ลดลงเมื่อเพิ่มขนาดจำลอง
  • 32 MiB (ค่าปัจจุบัน): ESTD_OVERALLOC_COUNT=993
  • 128 MiB: ประเมิน 540 ครั้ง; 192 MiB: ประเมิน 160 ครั้ง
  • 256 MiB: ประเมิน 0 ครั้งสำหรับ workload ที่ Advisor บันทึกไว้
  • ข้อจำกัด: ตัวเลขจาก V$PGA_TARGET_ADVICE เป็นการจำลอง workload ในอดีต ไม่ใช่ผลการเปลี่ยนค่าจริงหรือค่าที่ควรใช้ทันที
🔍
การวิเคราะห์
Advisor สนับสนุนสมมติฐานเรื่อง Workarea memory แต่ยังไม่พิสูจน์ Root Cause ของอาการช้า
ยืนยันแล้ว
ค่า PGA target ปัจจุบันมี Estimated Over-allocation
ค่าไม่เป็นศูนย์หมายความว่า Advisor ประเมินว่า target นั้นไม่พอรองรับ Workarea workload ที่ถูกบันทึกไว้ในช่วงจำลอง
เป็นไปได้
Workarea concurrency อาจทำให้ PGA target ไม่เพียงพอ
Sort, Hash Join หรือ Group By อาจใช้ Temporary space มากขึ้น แต่ต้องตรวจ Workarea histogram, extra bytes read/written และ SQL ช่วงเกิดอาการก่อนยืนยัน
ยังต้องตรวจยืนยัน
Buffer Cache 144 MiB เป็นคอขวด
ทีมไม่ใช้ขนาด Buffer Cache เป็นสูตรตายตัว แต่พิจารณา Cache Advice, Physical Reads และ OS Headroom ของ Workload เดียวกัน
🛠️
แนวทางตรวจสอบอย่างปลอดภัย
ยืนยัน workload และ OS headroom ก่อนทดลองปรับ PGA ทีละขั้น
  • เก็บ Baseline: Workarea executions optimal/one-pass/multipass, extra bytes read/written, DB Time และ Temp I/O ในช่วงงานเดียวกัน
  • ตรวจระบบปฏิบัติการ: Available memory, process memory และ paging/swapping เพื่อรักษา headroom ให้ OS และ Process อื่น
  • ทดลองทีละขั้น: ใช้ Advisor เป็นข้อมูลประกอบ เปลี่ยนค่าในช่วงควบคุม แล้วเปรียบเทียบ workload เดิม; PGA_AGGREGATE_TARGET เป็น target รวม ไม่ใช่ hard cap
  • แยก SGA จาก PGA: อย่าลด Java Pool หรือเพิ่ม Buffer Cache โดยอาศัยขนาด Parameter เพียงอย่างเดียว ต้องมี Component usage และ Cache Advice ที่ตรวจสอบได้
💡
ผลลัพธ์
ผลลัพธ์หลังปรับ Memory ตาม Workload จริง
💡

ระบบประมวลผลดีขึ้นโดยไม่ใช้สูตร Memory แบบตายตัว

ทีมทดลองปรับ PGA/SGA ทีละขั้นโดยรักษา OS Headroom และติดตาม Workarea ของระบบ หลังปรับแล้วงานประมวลผลทำงานได้ดีขึ้น แนวทางนี้ไม่ได้นำค่า 20% หรือค่า PGA 256 MiB ไปใช้เป็นสูตรทั่วไปกับทุกระบบ

อ่านเรื่องราวและรายละเอียดสำหรับ DBA/IT →

ฐานข้อมูลไม่ได้ช้าเฉพาะตอนที่เครื่องทำงานหนัก แต่อาจช้าเพราะงานหลายชุดกำลังต่อคิวรอกัน

เมื่อผู้ใช้ CRM ต้องรอนานขึ้น ทีมเปรียบเทียบ AWR (รายงาน Performance ที่ Oracle เก็บจากการทำงานจริงของระบบ) ระหว่างช่วงปกติกับช่วงที่มีปัญหา แล้วพบว่า Oracle ใช้เวลาส่วนใหญ่ไปกับการรอ Transaction อื่นปล่อย Lock ไม่ใช่การคำนวณบน CPU จุดนี้ทำให้ทิศทางการแก้ปัญหาเปลี่ยนไปทั้งหมด

🚨
จุดเริ่มต้น
หลักง่าย ๆ ที่ทำให้ตัวเลข Performance อ่านแล้วเห็นภาพ

DB Time (เวลารวมของงานฐานข้อมูล) แบ่งได้เป็นช่วงที่ Oracle กำลังประมวลผล และช่วงที่งานต้องหยุดรอ

DB Time = DB CPU + Wait Time (Non-idle)

ถ้านึกว่า DB Time มี 100 ส่วน ช่วงปกติ CPU time ใช้ไป 72.60 ส่วน แต่ช่วงที่ระบบช้าเหลือเพียง 27.02 ส่วน ขณะที่ enq: TM - contention (การรอ Lock ที่เกี่ยวข้องกับ Table หรือ Object) เพิ่มเป็น 61.98 ส่วน

เปรียบเหมือนช่องบริการที่พนักงานยังว่าง แต่ทำงานต่อไม่ได้เพราะเอกสารสำคัญถูกอีกคนถือไว้ การเพิ่มพนักงานจึงไม่ช่วยจนกว่าจะรู้ว่าใครถือเอกสารและทำไมจึงไม่ส่งต่อ

🔍
จุดพลิกจาก AWR
Wait Event คือชื่ออาการที่ Oracle บันทึกไว้ แต่ทีมต้องตามต่อว่าใครกำลังรอใคร

Wait Event (ชื่อที่ Oracle ใช้บอกว่า Session กำลังรออะไร) ช่วยชี้ทิศทาง ส่วน enq: TM - contention หมายถึงการรอ DML Enqueue ที่เกี่ยวข้องกับ Table หรือ Object แต่ชื่ออาการนี้ยังไม่ได้บอกว่า Transaction ใดเป็นต้นทาง

ทีมจึงไล่จาก Blocking Session (Session ที่ถือ Lock และทำให้งานอื่นต้องรอ) ไปยัง Waiting Session ที่ยังทำงานต่อไม่ได้ แล้วเชื่อมต่อกับ Enqueue Mode, Object และลำดับคำสั่ง SQL ในช่วงเวลาเดียวกัน

ระหว่างนั้นยังพบ log file sync และ log file parallel write จึงตรวจ Commit Frequency, LGWR และ I/O แยกต่างหาก เพื่อไม่ให้ปัญหา Redo กลบสาเหตุของ Lock Contention

🛠️
ทีมแก้อย่างไร
ตามรอยจาก Wait Event ไปถึง Transaction, Object และ SQL
  • หาเส้นทางการรอ: เชื่อม Blocking Session, Waiting Session, Object และ SQL ให้เป็นเหตุการณ์เดียวกัน
  • แก้เฉพาะจุด: ตรวจ Foreign Key และ Index เฉพาะ Object ที่เกี่ยวข้อง แทนการสร้าง Index แบบเหมารวม
  • แยกปัญหา Commit: ตรวจ log file sync, LGWR และ I/O โดยไม่รีบสรุปว่า Redo Log หรือ Storage เป็นสาเหตุ
💡
หลังดำเนินการ
ผู้ใช้กลับมาทำงานผ่าน CRM ได้คล่องขึ้น
💡

ผลลัพธ์ไม่ได้มาจากการเพิ่ม Hardware แต่มาจากการแก้ Transaction ที่รอกัน

หลังแก้จุดที่สร้าง Contention การรอ Lock ลดลงและผู้ใช้ CRM กลับมาทำงานได้คล่องขึ้น Case นี้จึงเป็นตัวอย่างของการใช้ AWR เปลี่ยน “อาการช้า” ให้กลายเป็นเส้นทางสืบหาสาเหตุที่แก้ได้จริง

อ่านเรื่องราวและรายละเอียดสำหรับ DBA/IT →

บทสรุป: แต่ละ Instance มี Wait Profile ต่างกัน จึงต้องตรวจแยกก่อนสรุป Root Cause

AWR สอง Instance ในช่วงเวลาเดียวกันยืนยันว่า Instance 1 มี Streams capture: waiting for archive log 6.4% ของ DB Time ขณะที่ Instance 2 มี Backup: sbtwrite2 6.1% และ io done 5.8% ข้อมูลนี้ช่วยชี้จุดตรวจสอบ แต่ยังไม่พิสูจน์ว่า Streams หรือ Backup เป็นสาเหตุของอาการช้าทั้งระบบ

🚨
Confirmed Evidence — AWR ราย Instance
📊 สัญญาณสำคัญไม่เหมือนกัน แม้เป็นช่วงเวลาเดียวกัน
AWR metricInstance 1Instance 2
CPU time28.5%37.4%
db file sequential read17.0%16.4%
Streams capture: waiting for archive log6.4%—
Backup: sbtwrite2—6.1%
io done—5.8%

ตัวเลขเป็นสัดส่วน DB Time จากรายงานแต่ละ Instance ในช่วงประมาณ 450 นาที ทีมจึงวิเคราะห์แยกต่อ Instance และเชื่อมผลด้วย Timeline เดียวกัน แทนการนำเปอร์เซ็นต์ข้าม Instance มารวมกัน

🔍
Evidence Boundary — อะไรยังเป็นสมมติฐาน
Wait Event บอกตำแหน่งที่เสียเวลา แต่ไม่บอกสาเหตุครบถ้วน
ยืนยันแล้ว
พบ Streams, Backup และ RAC-related waits ใน AWR
ยืนยันได้เฉพาะชื่อ Event จำนวน/เวลา Wait และสัดส่วน DB Time ตามช่วงรายงาน
เป็นไปได้
Capture lag, media manager หรือ workload ข้าม Instance อาจเกี่ยวข้อง
ต้องมี Capture status, Archive availability, Backup log, ASH และข้อมูล Storage/Interconnect ในช่วงเดียวกันจึงจะชี้ Root Cause ได้
จุดที่ทีมตรวจ
Archive Availability, Backup Timeline และ Hot Block
ตรวจเวลาและความสัมพันธ์ของแต่ละเหตุการณ์ก่อนเลือกแก้ Capture, Backup Schedule หรือ Workload Distribution
🛠️
Safe Next Steps — เก็บหลักฐานก่อนเปลี่ยนระบบ
เปรียบเทียบทุก Instance ด้วยช่วงเวลาและ Workload เดียวกัน
  • ตรวจ Capture process, lag และ Archive Log availability ในช่วงเดียวกับ AWR โดยไม่สรุปว่าต้องเพิ่ม Retention จนกว่าจะพบหลักฐาน
  • เทียบ Backup start/end, RMAN/SBT media-manager elapsed time และผลต่อ Foreground I/O ก่อนพิจารณาย้าย Schedule หรือแยก I/O path
  • ใช้ ASH/AWR ระบุ SQL, Object และ Instance ที่สัมพันธ์กับ gc waits แล้ววัดซ้ำหลังการเปลี่ยนแปลง
💡
ผลลัพธ์
RAC ทำงานเสถียรขึ้นหลังแก้ตาม Wait Profile ของแต่ละ Instance
💡

แก้ปัญหาโดยไม่เหมารวม RAC ทั้ง Cluster

ทีมปรับจุดที่เกี่ยวข้องกับ Streams Capture, Archive Availability, Backup และ Workload ตามอาการของแต่ละ Instance ทำให้ระบบทำงานได้เสถียรขึ้น โดยปกปิดชื่อระบบ Hostname, Schema, Object, SQL และข้อมูลลูกค้า

บทสรุป: Audit Trail เป็น Segment ที่มี Physical Reads สูง แต่ยังไม่ใช่หลักฐานของ Root Cause

AWR ช่วง 240.25 นาทีระบุว่า SYS.AUD$ มี Physical Reads 7,373,362 ครั้ง คิดเป็น 33.72% ในตาราง Segments by Physical Reads จึงควรตรวจ SQL และกิจกรรม Audit ที่เกี่ยวข้อง แต่ตัวเลขนี้เพียงอย่างเดียวยังพิสูจน์ไม่ได้ว่า Audit Trail ทำให้ธุรกรรมของระบบช้า

🚨
Confirmed Evidence — AWR Segment Statistics
📊 SYS.AUD$ ปรากฏเป็น Segment ที่อ่านจาก Storage สูง

สิ่งที่ AWR ชี้: SYS.AUD$ อยู่ใน Tablespace SYSAUX และมี 7,373,362 Physical Reads หรือ 33.72% ตามรายงาน ทีมจึงเชื่อม Segment นี้กับ SQL, Audit Configuration และ Retention Policy โดยปกปิดชื่อ Schema และ Object ธุรกิจอื่นทั้งหมด

🔍
Evidence Boundary — อย่าสรุปจาก Segment เดียว
Physical Reads ระบุตำแหน่งของ I/O ไม่ได้ระบุว่าใครอ่านหรืออ่านเพราะอะไร
ยืนยันแล้ว
SYS.AUD$ มีสัดส่วน Physical Reads สูงในช่วงรายงาน
ใช้เป็นจุดเริ่มต้นสำหรับหา SQL, Module, Audit mode และ Retention ที่สัมพันธ์กัน
เป็นไปได้
Audit volume, retention หรือ SQL ที่อ่าน Audit Trail อาจมีส่วน
ต้องตรวจ Audit configuration, ขนาด/การเติบโต, Execution Plan และ ASH/SQL statistics ก่อนสรุป
ไม่ควรทำทันที
ปิด Audit หรือ TRUNCATE SYS.AUD$ เพื่อให้เร็วขึ้น
อาจกระทบ Compliance และการตรวจสอบย้อนหลัง จึงต้องมีนโยบายเก็บข้อมูล การ Archive และแผนย้อนกลับที่อนุมัติแล้ว
🛠️
Safe Next Steps — Performance และ Compliance ต้องไปด้วยกัน
ระบุ SQL และนโยบาย Audit ก่อนเลือกวิธีจัดการ
  • หา SQL/Module ที่อ่านหรือสร้างข้อมูล Audit ในช่วงเดียวกับ AWR และตรวจว่ากิจกรรมนั้นเป็น Foreground impact จริงหรือไม่
  • ทบทวน Audit mode, Retention และข้อกำกับกับเจ้าของข้อมูล; Archive ก่อน Purge ตามขั้นตอนที่รองรับกับรุ่นและรูปแบบ Audit ที่ใช้งาน
  • หากใช้ Traditional Audit Trail ให้ประเมิน DBMS_AUDIT_MGMT ตามเอกสาร Oracle และยืนยันผลด้วย AWR/SQL metrics หลังเปลี่ยน
💡
ผลลัพธ์
ลดภาระจาก Audit Trail พร้อมรักษาข้อกำหนด Compliance
💡

ระบบตอบสนองดีขึ้นหลังจัดการ SYS.AUD$ อย่างถูกวิธี

ทีมจัดการ Audit Data, Retention และ Housekeeping ตาม Audit Mode ที่ใช้งาน ทำให้ภาระ I/O ลดลงและระบบตอบสนองดีขึ้น โดยไม่ปิด Audit หรือทำลายข้อมูลที่ต้องใช้ตรวจสอบย้อนหลัง

อ่านเรื่องราวและรายละเอียดสำหรับ DBA/IT →

จำนวน Transaction ใกล้เคียงกัน แต่เวลาที่ Oracle ใช้ยืนยันแต่ละรายการกลับต่างกันมาก

AWR ช่วงเดียวกันพบว่า RAC ทั้งสอง Instance รับประมาณ 71 Transaction ต่อวินาที และมีจำนวน log file sync เกือบเท่ากัน แต่ Instance 1 รอเฉลี่ย 10ms ขณะที่ Instance 2 รอเพียง 4ms ทีมจึงเปลี่ยนคำถามจาก “งานกระจายเท่ากันหรือไม่” เป็น “เวลาใน Commit path ไปเสียอยู่ตรงไหน”

🚨
จุดเริ่มต้น
เข้าใจ Redo และ log file sync ก่อนอ่านความต่าง 10ms กับ 4ms

Redo คือสมุดบันทึกการเปลี่ยนแปลงที่ Oracle ใช้กู้ข้อมูลเมื่อระบบขัดข้อง ส่วน LGWR (Log Writer) คือ Process ที่นำ Redo ไปเก็บใน Online Redo Log

Application ส่ง COMMIT → LGWR เขียน Redo → Oracle ยืนยัน Transaction

log file sync คือเวลาที่งานรอวงจรนี้ Instance 1 รอรวม 2,420 วินาทีหรือ 38.3% ของ DB Time ส่วน Instance 2 รอรวม 920 วินาทีหรือ 25.7%

🔍
สิ่งที่ AWR เปิดเผย
จำนวนงานใกล้กัน แต่น้ำหนักของ Transaction ไม่เท่ากัน

Instance 1 สร้าง Redo ประมาณ 3,791 bytes ต่อ Transaction ขณะที่ Instance 2 อยู่ที่ประมาณ 1,501 bytes ต่างกันกว่า 2.5 เท่า ความต่างนี้เกิดพร้อมกับ log file sync ที่ 10ms กับ 4ms แต่ยังต้องวิเคราะห์ต่อก่อนกล่าวว่า Redo เป็นสาเหตุเพียงอย่างเดียว

log file parallel write ซึ่งสะท้อนเวลาฝั่ง LGWR เขียน Redo เฉลี่ยประมาณ 1ms ทั้งสอง Instance จึงไม่ควรสรุปทันทีว่า Disk ของฝั่งหนึ่งช้ากว่า ทีมตรวจ LGWR scheduling, Commit pattern และ Backup timeline ร่วมกัน

🛠️
ทีมแก้อย่างไร
ใช้ RAC เป็นข้อมูลเปรียบเทียบ แล้วตามรอย Commit path ทีละส่วน
  • เทียบงานให้ถูก: ตรวจ Transaction rate, จำนวน COMMIT, Waits ต่อ Transaction และ Redo ต่อ Transaction
  • แยกเวลาที่รอ: เทียบ log file sync กับ log file parallel write, LGWR scheduling และ I/O latency
  • ตรวจสิ่งที่เกิดพร้อมกัน: เชื่อม Backup และ Cluster waits ด้วย Timeline ก่อนเลือกจุดปรับ
💡
หลังดำเนินการ
Transaction ตอบสนองดีขึ้นและ Oracle RAC ทำงานเสถียรขึ้น
💡

แก้ Commit path จากหลักฐาน ไม่ได้เดาจากชื่อ Wait เพียงตัวเดียว

ทีมปรับจุดที่เกี่ยวข้องกับ Commit Frequency, LGWR, Storage และ Job Timeline แยกต่อ Instance ทำให้การตอบสนองของ Transaction และความเสถียรของ RAC ดีขึ้น

อ่านเรื่องราวและรายละเอียดสำหรับ DBA/IT →

สถานการณ์: ระบบช้าเมื่อ Workload และจำนวน Connection เพิ่มขึ้น

ทีมวิเคราะห์ร่วมกันทั้ง SQL tuning, direct path read, log file sync, Connection Management และ Concurrent Load Test เพื่อแยกว่าปัญหาเกิดจาก Access Path, Commit Path หรือรูปแบบ Load ของ Application

🗂️
อาการและข้อมูลที่ทีมตรวจ
SQL, Wait Events และ Connection ต้องอ่านเป็นภาพเดียวกัน
  • SQL และ Execution Plan: ตรวจ Function บนคอลัมน์, Predicate, Full Scan และ Access Path ที่เกิดขึ้นจริง
  • Wait Events: เชื่อม direct path read และ log file sync กับ SQL และช่วงเวลาที่ผู้ใช้พบอาการ
  • Connection และ Load Test: ทดสอบรูปแบบ Concurrency, Response Time, Throughput และ Error ภายใต้ Load ที่ใกล้เคียงการใช้งานจริง
🔍
Technical Review — หลักการทั่วไปไม่ใช่ข้อพิสูจน์ของ Case
Function อาจเปลี่ยน Access Path แต่ไม่ได้ทำให้ Index ใช้ไม่ได้ทุกกรณี
หลักการทั่วไป
Expression บนคอลัมน์อาจกระทบการใช้ Index
ผลขึ้นกับ Predicate, Datatype, Statistics, Optimizer และ Function-based Index ต้องดู Execution Plan และ runtime statistics จริง
ต้องพิสูจน์
direct path read และ log file sync เกิดจากอะไร
ต้องมี AWR/ASH, SQL ID ที่ปกปิดอย่างเหมาะสม, Object statistics และ Timeline ของระบบประกอบ
ไม่เผยแพร่
ชื่อ Instance, Schema, Procedure, Table, Index, SQL, DDL และ Scenario ID
ข้อมูลภายในทั้งหมดถูกตัดออก และไม่ควรสร้างรหัส Error หรือตัวเลขผลลัพธ์ขึ้นใหม่
🛠️
สิ่งที่ทีมดำเนินการ
ปรับ SQL, Access Path และ Connection ก่อนทดสอบ Concurrent Load ซ้ำ
  • ปรับ SQL และ Predicate ที่ทำให้ Access Path ไม่เหมาะสม รวมถึงประเมิน Function-based Index เมื่อเข้ากับ Workload
  • ปรับจุดที่เกี่ยวข้องกับ Commit และ Connection Lifecycle โดยพิจารณาทั้ง Application กับ Oracle Database
  • ทำ Concurrent Load Test ซ้ำเพื่อดู Response Time, Throughput และ Error ภายใต้ Scenario ที่กำหนด
💡
ผลลัพธ์
ระบบรองรับ Workload ที่ต้องการได้ดีขึ้น
💡

แก้ครบทั้ง SQL, Wait Event และ Connection

หลังปรับ SQL, Access Path, Commit และ Connection ที่เกี่ยวข้อง ระบบผ่านการใช้งานตาม Load ที่ลูกค้าต้องการและตอบสนองดีขึ้น โดยปกปิดชื่อ Instance, Schema, Procedure, Table, Index, SQL, DDL และ Scenario ภายในทั้งหมด

💾 Incident Recovery, Availability & Capacity 3

Oracle บอกว่าพื้นที่ไม่พอ แต่พอไปดู Disk กลับยังว่าง

ผู้ใช้บันทึก Transaction ไม่ได้และ Oracle แสดง ORA-01653 ทุกคนจึงคิดว่า Disk เต็ม แต่เมื่อตรวจแล้วกลับยังมีพื้นที่เหลือ สาเหตุคือ Oracle ใช้พื้นที่ผ่าน Datafile และไฟล์เดิมโตถึงเพดานแล้ว

🚨
จุดเริ่มต้น
เข้าใจเพียง Table, Tablespace และ Datafile ก็แกะปัญหานี้ได้

Table คือข้อมูลที่ Application ใช้, Tablespace คือพื้นที่ภายใน Oracle ที่ Table ใช้งาน และ Datafile คือไฟล์จริงของ Tablespace ที่อยู่บน Disk

Table → Tablespace → Datafile → Disk

Table ใช้พื้นที่ว่างบน Disk โดยตรงไม่ได้ แต่ใช้ได้เฉพาะพื้นที่ใน Datafile ต่อให้ Disk ยังว่าง หาก Datafile โตต่อไม่ได้ Oracle ก็ยังฟ้องว่าพื้นที่ไม่พอ

🔍
จุดพลิกจาก Error
Datafile เดิมของ Smallfile Tablespace โตถึงเพดานใกล้ 32 GB

ทีมอ่านชื่อ Table และ Tablespace จาก ORA-01653 แล้วพบว่าเป็น Smallfile Tablespace ที่ใช้ Block Size 8 KB ส่วน Datafile เดิมโตถึงขนาดสูงสุดแล้ว จึง Autoextend หรือ Resize ต่อไม่ได้

Table
ข้อมูลต้องการพื้นที่เพิ่ม
Error ระบุ Table และ Tablespace ที่เกิดปัญหา
Datafile
ไฟล์เดิมโตต่อไม่ได้
Smallfile 8 KB ถึงเพดานใกล้ 32 GB ต่อไฟล์
Disk
ยังมีพื้นที่ว่าง
รองรับการสร้าง Datafile ใหม่ให้ Tablespace เดิม
🛠️
ทีมแก้อย่างไร
เพิ่ม Datafile ใหม่ให้ Tablespace เดิม
  • อ่าน Error: ระบุ Table และ Tablespace ที่ขยายไม่ได้
  • ตรวจ Datafile: ยืนยันว่าไฟล์เดิมถึงเพดานและโตต่อไม่ได้
  • ใช้พื้นที่บน Disk: เพิ่ม Datafile ใหม่เข้าไปใน Tablespace เดิม
  • ป้องกันซ้ำ: ติดตาม Growth Rate และ Time-to-full ก่อนพื้นที่กระทบผู้ใช้
💡
ผลลัพธ์
Transaction กลับมาบันทึกได้ และพื้นที่ไม่ใช่เรื่องที่ต้องรอให้เต็มก่อนจึงค่อยแก้
💡

Oracle มีไฟล์ใหม่สำหรับใช้พื้นที่บน Disk

เมื่อเพิ่ม Datafile ใหม่ Oracle สามารถขยาย Table และรับ Transaction ต่อได้ ผู้ใช้กลับมาทำงานตามปกติ และทีมวาง Monitoring ก่อนเกิด ORA-01653 รอบถัดไป

อ่านเรื่องราวและรายละเอียดสำหรับ DBA/IT →

สถานการณ์: ระบบ DR ตามข้อมูลจากระบบหลักไม่ทัน

ทีมแยก Transport Lag, Apply Lag และ Missing Archive Log Sequence เพื่อระบุว่าการส่ง Log หรือการ Apply หยุดที่จุดใด ก่อนเลือก Recovery Path ที่กระทบระบบน้อยที่สุด

🚨
อาการและผลกระทบ
ข้อมูลฝั่ง DR ไม่อัปเดตตามระบบหลัก

Managed Recovery เดินหน้าต่อไม่ได้เพราะลำดับ Archive Log ไม่ต่อเนื่อง ทำให้ระบบสำรองตามหลัง Production และกระทบความพร้อมตามแผน DR

🔍
แนวทางวิเคราะห์จากข้อมูลที่มี
Archive Log Gap เป็นไปได้ แต่คำว่า “ไฟล์หาย” ยังไม่ใช่ Root Cause

Archive Log Sequence ที่ไม่ต่อเนื่องอาจทำให้กระบวนการ Recovery หรือ Apply เดินหน้าต่อไม่ได้ แต่ต้องตรวจสถานะจริงก่อน เพราะ Transport Gap, Apply Lag และไฟล์ถูกลบหรือเสียหายต้องใช้แนวทางแก้ต่างกัน:

  • Transport: ตรวจ Destination status, Error, Network path และ Sequence ที่ส่งสำเร็จล่าสุด
  • Apply: ตรวจ Sequence ที่รับแล้วเทียบกับ Sequence ที่ Apply และเหตุผลที่ Managed Recovery หยุด
  • Availability: ค้นหา Archive Log ที่ระบบหลัก, Backup และ Media อื่นก่อนสรุปว่าไม่สามารถกู้ไฟล์ได้
🛠️
แนวทางเลือก Recovery อย่างปลอดภัย
เริ่มจากเติม Log Gap ก่อนพิจารณา Roll-forward หรือ Re-instantiate

ทีมเริ่มจากวิธีที่กระทบน้อยและตรวจสอบได้ ก่อนพิจารณาวิธีที่ใช้เวลาและทรัพยากรมากกว่า:

  • เติม Gap: Restore/Register Archive Log ที่ขาด หากยังพบในระบบหลักหรือ Backup
  • Roll-forward: ประเมิน Incremental Recovery ตาม SCN เมื่อ Version และรูปแบบระบบรองรับ
  • Re-instantiate: ใช้เมื่อ Gap กู้ไม่ได้หรือความเสี่ยงของวิธีอื่นสูงกว่า โดยต้องมี Backup, Capacity, Downtime และ Rollback plan
  • Verification: ทดสอบ Transport, Apply, RPO/RTO และ Readiness ตาม Runbook ไม่ใช้เพียงสถานะ “Sync” หนึ่งค่า
💡
ผลลัพธ์
กู้ Archive Log Gap และทำให้ DR กลับมาตามข้อมูลได้
💡

ระบบ DR กลับมา Apply Log ต่อเนื่อง

หลังเติม Missing Sequence และแก้เส้นทาง Transport/Apply ที่เกี่ยวข้อง ระบบ DR กลับมาตามข้อมูลจากระบบหลักได้ ทีมปรับ Archive Log Retention และ Monitoring ให้เห็น Transport Lag, Apply Lag และ Gap ก่อนกระทบความพร้อมของระบบ

สถานการณ์: Oracle หยุดประมวลผลจากการเติบโตใน SYSAUX

ทีมตรวจ V$SYSAUX_OCCUPANTS, Segment Growth, Audit Mode และรูปแบบ DDL เพื่อหาว่า Component ใดใช้พื้นที่จริง ก่อนกู้ Capacity และควบคุมการเติบโตระยะยาว

🚨
อาการและผลกระทบ
ระบบประมวลผลต่อไม่ได้เมื่อพื้นที่ SYSAUX ไม่เพียงพอ

พื้นที่ใน SYSAUX เติบโตจากข้อมูลภายในและ Audit Activity จนกระทบการทำงานของฐานข้อมูล ทีมต้องกู้ Capacity พร้อมหา Occupant ที่เป็นต้นทางเพื่อป้องกันเหตุซ้ำ

🔍
แนวทางวิเคราะห์จากข้อมูลที่มี
Audit Trail และ DDL อาจทำให้พื้นที่เติบโต แต่ต้องหา Occupant และ Segment ก่อน

SYSAUX รองรับองค์ประกอบภายในหลายประเภท ขณะที่ตำแหน่ง Audit Trail แตกต่างตาม Oracle version และ Audit mode การพบ SYSAUX โตจึงยังไม่พิสูจน์ว่า DDL Audit เป็น Root Cause:

Occupant
ระบุผู้ใช้พื้นที่ SYSAUX
ตรวจ V$SYSAUX_OCCUPANTS และ Segment growth เพื่อหาว่า Component ใดใช้พื้นที่จริง
Audit Mode
ยืนยัน Audit Trail และ Policy
ตรวจ Traditional/Unified Auditing, Trail location, Retention และจำนวน DDL ที่บันทึกใน Incident window
Application
พิสูจน์รูปแบบ CREATE/DROP
เก็บ SQL/DDL frequency แบบปกปิดชื่อ Object ก่อนเชื่อมพฤติกรรมแอปพลิเคชันกับ Audit growth
🛠️
สิ่งที่ทีมดำเนินการ
แยก Emergency Capacity ออกจากการแก้สาเหตุระยะยาว

ทีมแยกการกู้บริการเร่งด่วนออกจากการควบคุมการเติบโตในระยะยาว:

  • Emergency Capacity: Add/Resize Datafile หลังตรวจ Storage, Backup และ Tablespace Configuration เพื่อให้ระบบกลับมาทำงาน
  • Audit Housekeeping: ใช้ DBMS_AUDIT_MGMT ตาม Oracle version, Audit mode, Retention และข้อกำหนด Compliance พร้อม Backup และทดสอบก่อน Purge
  • Application Design: หากหลักฐานพบ CREATE/DROP ซ้ำ ให้ประเมินการ Reuse Object หรือ Global Temporary Table ตาม Transaction semantics และทดสอบผลกระทบ
💡
ผลลัพธ์
ระบบกลับมาประมวลผลและควบคุมการเติบโตของ SYSAUX ได้
💡

แก้ทั้ง Capacity เร่งด่วนและสาเหตุการเติบโตระยะยาว

หลังเพิ่ม Capacity และจัดการ Audit/Occupant ตามวิธีที่เหมาะกับ Oracle Version ระบบกลับมาทำงานได้ และมีแนวทาง Housekeeping เพื่อชะลอการเติบโต โดยไม่ลด Audit Coverage ที่องค์กรต้องใช้ด้านความปลอดภัยและ Compliance

อ่านเรื่องราวและรายละเอียดสำหรับ DBA/IT →

ระบบงานไอทีหรือฐานข้อมูลในองค์กรของคุณกำลังประสบปัญหาเหล่านี้?

ทีมงานผู้เชี่ยวชาญของ VT Technology ยินดีช่วยเหลือ ตรวจสอบ จูนนิ่งแก้ไข และวางมาตรการด้านความปลอดภัยและการสำรองข้อมูลให้องค์กรของคุณทำงานได้อย่างปลอดภัย 24x7

📝 ติดต่อวิเคราะห์ปัญหาระบบฟรี
🔧

ระบบของคุณมีปัญหาคล้ายกันไหม?

จากประสบการณ์กว่า 20 ปี ทีม VT Technology พร้อมวิเคราะห์และแก้ไขปัญหา Oracle Database ของคุณ
ทั้ง Performance Tuning, Emergency Recovery, RAC และอื่นๆ

📞 ปรึกษาทีมผู้เชี่ยวชาญฟรี ดูบริการทั้งหมด →

✅ ไม่มีค่าใช้จ่ายในการปรึกษาเบื้องต้น  |  ✅ ทีมผู้เชี่ยวชาญ OCP/OCE  |  ✅ รับงานทั่วไทย

FAQ

คำถามที่พบบ่อยเกี่ยวกับ Oracle Database

คำถามและคำตอบจากประสบการณ์จริงกว่า 20 ปี ของทีม VT Technology

log file sync คือ Wait Event ที่ Session รอให้ LGWR (Log Writer) flush redo และตอบกลับหลัง COMMIT ไม่มีเกณฑ์เปอร์เซ็นต์เดียวที่ใช้ตัดสินได้กับทุกระบบ ควรตรวจสอบข้อมูลที่สัมพันธ์กัน:

  • Average wait และจำนวนครั้งที่รอ — ดูทั้ง latency และปริมาณ COMMIT
  • log file parallel write และ I/O latency — แยกเวลาการเขียน redo ออกจากเวลาส่วนอื่น
  • Commit frequency และ LGWR scheduling — ตรวจรูปแบบธุรกรรมและทรัพยากรที่ LGWR ได้รับ

การเพิ่มขนาด Redo Log มีผลหลักต่อความถี่ของ log switch และไม่ใช่วิธีแก้ log file sync สำหรับทุก Root Cause

enq: TM - contention แสดงว่ามีการรอ DML enqueue ที่เกี่ยวข้องกับ Table หรือ Object โดย Foreign Key ที่ไม่มี Index เป็นหนึ่งในสาเหตุที่เป็นไปได้ แต่ Wait Event เพียงอย่างเดียวยังไม่พิสูจน์ Root Cause

สิ่งที่ควรตรวจ: Blocking Session, Waiting Session, Object, enqueue mode และ SQL/DML ในช่วงเวลาเดียวกับเหตุการณ์ ก่อนพิจารณาสร้าง Index หรือเปลี่ยน Application

AWR (Automatic Workload Repository) คือรายงานสุขภาพของระบบ Oracle ที่เก็บสถิติโดยอัตโนมัติทุก 1 ชั่วโมง ประกอบด้วย:

  • 📊 Top 5 Wait Events — บอกว่าระบบ "รอ" อะไรมากที่สุด
  • 🔥 Top SQL — SQL ที่กิน CPU/I/O สูงสุด
  • 💾 Segment Statistics — ตารางหรือ Index ที่ถูก Access มากที่สุด
  • 🧠 Memory Advisor — แนะนำขนาด SGA/PGA ที่เหมาะสม

AWR เป็นจุดเริ่มต้นของการ Tune ทุกครั้ง — ทีม VT Technology ใช้ AWR เป็นพื้นฐานในทุก Consulting Case

Oracle RAC (Real Application Clusters) รัน Oracle Database บนหลายเครื่องพร้อมกัน ข้อดีคือ High Availability และ Load Balancing แต่การ Tune RAC มีความซับซ้อนกว่า เพราะต้องวิเคราะห์ AWR ทุก Instance แยกกัน — Wait Profile ของแต่ละ Instance อาจต่างกัน เช่น Instance หนึ่งพบ Streams wait ขณะที่อีก Instance พบ Backup wait แต่ยังต้องตรวจ Timeline และหลักฐานประกอบก่อนสรุป Root Cause

ขั้นตอนเบื้องต้นที่แนะนำ:

  1. ดู AWR Report ของช่วงเวลาที่ระบบช้า — เปิดด้วย @$ORACLE_HOME/rdbms/admin/awrrpt.sql
  2. ดู Top 5 Wait Events — นี่คือสัญญาณแรกว่าปัญหาอยู่ที่ไหน
  3. วิเคราะห์ Top SQL — ดู Execution Plan ด้วย DBMS_XPLAN.DISPLAY_AWR
  4. ตรวจ Segment Statistics — ดูว่ามี System Table (เช่น AUD$) ติดอันดับ Hot Segment หรือไม่

หากต้องการความช่วยเหลือ ติดต่อทีม VT Technology ได้ทันที