กรณีศึกษา & บันทึกการแก้ปัญหาระบบ
ถอดบทเรียนกรณีศึกษาจริงจากการเข้าไปแก้ปัญหาความปลอดภัย และจูนประสิทธิภาพระบบฐานข้อมูลออราเคิลให้ลูกค้าองค์กร
ผ่าตัดวิกฤต Epicor ERP อืดสนิท — ถอดรหัสปัญหาซ้อนทับ 3 ชั้น
บทนำ: วิกฤต Perfect Storm ในระบบ ERP
ในโลกของระบบฐานข้อมูลระดับ Enterprise ปัญหาร้ายแรงมักไม่ได้เกิดจากสาเหตุเดียว แต่เกิดจากหลายปัจจัยซ่อนเร้นมาบรรจบกันในเวลาเดียว นี่คือบันทึกการทำงานของทีมที่ปรึกษาที่เข้าสืบสวนคดี CPU Server พุ่ง 100% ต่อเนื่อง จนใช้งานไม่ได้
ลูกค้าประเมินเบื้องต้นว่าสาเหตุเกิดจาก "ข้อมูลเยอะเกินไป" จึงทำการ Purge ลบข้อมูลบางส่วน ลดปริมาณจาก 1,000,000 แถว เหลือ 400,000 แถว แม้ว่าระบบจะกลับมารวดเร็วทันตาเห็นในช่วงแรก แต่เพียง 2 สัปดาห์ข้อมูลสะสมเพิ่มขึ้นอย่างรวดเร็ว และ CPU ก็พุ่งกลับมาชนเพดาน 100% อีกครั้ง ซึ่งเป็นข้อพิสูจน์ว่า การแก้ปัญหาที่ปลายเหตุ ไม่สามารถหยุดยั้งปัญหานี้ได้อย่างแท้จริง
จากการวิเคราะห์ Execution Plan และ Business Logic เชิงลึก พบว่าวิกฤต CPU 100% เกิดจาก 3 ปัญหาร้ายแรงที่ขัดแย้งและหนุนเสริมกันอยู่:
ทีมงานวางแผนการแก้ไขเป็นขั้นตอนเพื่อปลดล็อกประสิทธิภาพสูงสุด โดยไม่ต้องเสี่ยงลบข้อมูลดิบ:
- Step 1: หยุดการสร้างขยะค้างท่อ (แก้ Business Logic)
ประสานงานกับทีมโอเปอเรชันเพื่อบังคับใช้กระบวนการ "Job Closing" เมื่อผลิตเสร็จ และรันโปรเซส "Capture COS/WIP Activity" เพื่อล้างมูลค่างานระหว่างทำ (WIP) และลงบัญชีแยกประเภททั่วไป (GL) อย่างสมบูรณ์ ส่งผลให้ Active Records ที่ค้างสะสมเปลี่ยนสถานะ (WIPCleared = 1) - Step 2: ปลดล็อก Performance ทันที
เมื่อปริมาณ Active Records ลดลงอย่างมหาศาล ฐานข้อมูลสามารถนำ Index กลับมาใช้งานสืบค้นข้อมูลได้ทันที ส่งผลให้ CPU ร่วงลงสู่สภาวะปกติและเสถียร - Step 3: วางแผนป้องกันถาวรในระยะยาว
เสนอแผนอัปเกรดฐานข้อมูลเป็น SQL Server 2019+ เพื่อใช้งานฟีเจอร์ Scalar UDF Inlining ซึ่งจะช่วยแก้ไขจุดอ่อนของแอปพลิเคชันได้ในระยะยาว
ความยั่งยืนที่เหนือกว่าการแก้ปัญหาปลายเหตุ
ปัญหาระบบขององค์กรขนาดใหญ่เชื่อมโยงกันเสมอ การลบข้อมูล (Purging) เป็นเพียงการประทังอาการชั่วคราว หากต้องการความเสถียรที่ถาวร ต้องวิเคราะห์ให้ครอบคลุมทั้งพฤติกรรมการใช้งาน Business Process, Application Code, และ Database Engine
อัปเกรด RAM เกือบ 100GB ก็ไม่ช่วย — แก้ปัญหาระบบหน่วงใน Oracle 12c & GlassFish
"ระบบช้าจัง ขอเพิ่ม RAM อีกได้ไหม?"
นี่คือประโยคคลาสสิกเมื่อแอปพลิเคชันเริ่มมีปัญหาคอขวด แต่จากประสบการณ์กว่า 20 ปี เราพบว่า "การเพิ่ม Hardware ไม่ใช่ยาสารพัดนึกเสมอไป" เคสนี้พิสูจน์ว่า ความเข้าใจสถาปัตยกรรมสำคัญกว่าการถม Resource เพียงอย่างเดียว
ระบบเป็นสถาปัตยกรรมแบบ 3-Tier (Oracle 12c ➡️ GlassFish ➡️ Client Web) อาการผิดปกติคือเมื่อ Concurrent Users เกิน 60 คน แอปพลิเคชันจะหน่วงจนค้าง ทั้งที่ปกติ 60 sessions ถือว่าน้อยมากสำหรับ Oracle Database
ทีมงานเดิมย้ายระบบจาก Solaris (RAM 32 GB) ไปรันบน Linux พร้อมอัปเกรดจัดเต็ม RAM 96 GB และปรับ SGA/PGA ตาม Advisor อย่างครบถ้วน แต่ระบบยังคงช้าและหน่วงเหมือนเดิมทุกประการ!
ทีมที่ปรึกษาวิเคราะห์ Connection Behavior ระหว่างแอปพลิเคชันและฐานข้อมูล จนพบความผิดปกติ:
- Dedicated Server Process: ทุกครั้งที่มี Request จากผู้ใช้งาน ระบบจะสร้าง OS Process ใหม่บนฐานข้อมูลเสมอ เนื่องจากโค้ดฝั่งแอปพลิเคชันเปิดและปิดการเชื่อมต่ออยู่ตลอดเวลา
- Logon Storm & Context Switching: การสถาปนาการเชื่อมต่อใหม่นับร้อยครั้งพร้อมกันทำให้ CPU ต้องรับภาระมหาศาลในการทำ Handshake (การอัปเกรด RAM เป็น 96 GB จึงไม่ช่วยลด Overhead ตรงนี้ได้เลย)
ทีมงานเข้าดำเนินการแก้ไขที่ต้นตอสถาปัตยกรรมการเชื่อมต่อของระบบ Java และ Oracle:
- 1. ทำ Connection Pooling บน GlassFish:
เปลี่ยนพฤติกรรมจาก "สร้างการเชื่อมต่อใหม่ทุกครั้ง" เป็น "สร้างเตรียมรอไว้และนำกลับมาใช้งานซ้ำ" ลดขั้นตอน Handshake และยกเลิกการสร้าง OS Process ซ้ำซ้อน - 2. ปรับจูนพารามิเตอร์ Oracle Database:
ปรับค่าPROCESSESและSESSIONSให้รองรับ Max Pool Size ที่ตั้งไว้บน GlassFish เพื่อให้เซิร์ฟเวอร์จัดสรรทรัพยากรล่วงหน้าได้อย่างพอเหมาะ - ผลลัพธ์: อาการล่าช้าและหน่วงหายไปอย่างสมบูรณ์แบบ ระบบรองรับผู้ใช้งานได้ตามขีดความสามารถที่ควรจะเป็น
มองภาพรวมระบบมากกว่าแค่การขยายเซิร์ฟเวอร์
Database Tuning ไม่ใช่เพียงการเพิ่ม RAM หรือปรับพารามิเตอร์หน่วยความจำเฉพาะจุด แต่ต้องอาศัย "ความเข้าใจแบบ End-to-End" ตั้งแต่โค้ดแอปพลิเคชัน, เครือข่ายการรับส่ง, ไปจนถึงสถาปัตยกรรมระดับล่างสุดของ Database Engine
ปลดล็อกวิกฤตระบบผลิตค้าง — Instance Tuning เมื่อเพิ่มแรมเป็น 2 เท่าก็ยังทำงานไม่ได้
บทนำ: เมื่อเพิ่มแรมเป็น 2 เท่าก็ยังทำงานไม่ได้
ในระบบฐานข้อมูลรุ่นเก่า เช่น Oracle 9i บ่อยครั้งที่ขีดจำกัดทางประสิทธิภาพไม่ได้เกิดจากความสามารถของตัวเครื่องเซิร์ฟเวอร์ แต่เกิดจากการกำหนดค่าพารามิเตอร์ภายใน การซื้อฮาร์ดแวร์ใหม่โดยไม่มีการทำ Instance Tuning เปรียบเสมือนการขยายถังน้ำแต่ท่อส่งน้ำยังมีขนาดเท่าเดิม
โรงงานประสบปัญหาระบบค้างบ่อยครั้งในสายการผลิต โดยเวลาประมวลผลต่อ 1 Batch เพิ่มขึ้นจากเดิม 30 วินาที กลายเป็นหลายสิบนาที จนระบบเกิดอาการค้าง ลูกค้าเพิ่มแรมจาก 1 GB เป็น 2 GB แต่ความเร็วยังคงช้าและค้างเหมือนเดิม
ทีมงานตรวจประเมินพารามิเตอร์ผ่านคำสั่ง show parameter และพบปัญหาระดับสถาปัตยกรรม:
- SGA Default Limits: ผู้รับเหมาติดตั้งระบบในอดีตตั้งค่าหน่วยความจำ SGA (System Global Area) ไว้เป็นค่าเริ่มต้น (Default) เพียง 128 MB เท่านั้น
- Workload ไม่สมดุล: เมื่อข้อมูลและทรานแซกชันสะสมเพิ่มขึ้นหลายสิบปี ขนาด SGA 128 MB กลายเป็นคอขวด และเนื่องจากไม่มีการปรับ Instance ให้รับรู้แรมใหม่ Oracle Database จึงไม่สามารถนำแรม 2 GB ที่เพิ่มเข้ามาใช้งานประมวลผลได้เลย
ทีมที่ปรึกษาวางแผนปรับแต่งหน่วยความจำและตัวแปรผ่าน Parameter File (init.ora / spfile):
- ปรับแต่งด้วย Buffer Cache Size Advisor: วิเคราะห์และปรับขนาด Buffer Cache เพื่อเพิ่มอัตราการเจอข้อมูลในแรม (Cache Hit Ratio) และลด Physical Reads
- ขยายพื้นที่หน่วยความจำ SGA: ปรับขยาย SGA ให้สัมพันธ์กับแรม 2 GB โดยคำนวณภายใต้เงื่อนไข:
Total SGA + Aggregate PGA Target + OS Memory <= Physical RAMเพื่อไม่ให้เกิด Overflow ไปใช้ Swap Space
หลังการปรับค่าและรีสตาร์ทระบบ เวลาประมวลผลต่อ 1 Batch ลดลงจากหลายสิบนาที กลับมาอยู่ในระดับ "วินาที" ตามปกติ อาการค้างหายไป 100% สายการผลิตเดินหน้าได้เต็มกำลัง และประหยัดงบประมาณลงทุนซื้อเซิร์ฟเวอร์ใหม่ได้อย่างคุ้มค่า
วิเคราะห์และปรับจูนประสิทธิภาพระบบ LIC โทรคมนาคมระดับชาติ ด้วย AWR Report
บทนำ: ประมวลผล CDR 40 ล้านรายการ/วัน แต่ระบบช้าจนงานไม่ทัน
ระบบ Local Interconnect (LIC) ของหน่วยงานโทรคมนาคมระดับชาติ ทำหน้าที่ประมวลผล Call Detail Record (CDR) สูงถึง 40 ล้านรายการต่อวัน และรองรับการสืบค้นเลขหมาย MNP กว่า 60–80 ล้านครั้งต่อวัน ผ่านการวิเคราะห์ AWR Report เชิงลึก ทีมพบว่าต้นตอปัญหาไม่ได้อยู่ที่ฮาร์ดแวร์ แต่เป็นปัญหาการตั้งค่าและการจัดการทรัพยากรภายใน
ระบบเกิดความล่าช้าอย่างหนักใน 2 กระบวนการสำคัญ: Rating Process (ประมวลผลรายวัน) และ Summary Process (สรุปผลข้อมูล) จากการวิเคราะห์ CPU and Wait Time Tuning Dimensions พบว่าทั้งสอง Process ตกอยู่ในโซนแดง (Needs Instance/RAC Tuning) Wait time ทะลุ 74–75% แบบแปลว่าเพิ่ม CPU จะไม่ช่วยอะไรเลย
ทีมผู้เชี่ยวชาญเก็บและวิเคราะห์ AWR Snapshot แล้วพบสาเหตุชัดเจน 4 จุด:
- Scheduler ชนกัน (resmgr:cpu quantum = 22% of DB Time): Automated Job ของ Oracle เช่น
dbms_stats.gather_database_statsทำงานซ้อนทับกับช่วงเวลาที่ Process หลักกำลังทำงาน - Resource Manager ตั้งค่าไม่เหมาะสม: Resource Plan ที่ใช้อยู่กำหนดให้ LIC Process (อยู่ใน
OTHER_GROUPS) ใช้ CPU ได้เพียง 70% สูงสุด แทนที่จะเป็น 100% - Parallelism คอขวด (PX qref latch = 12.37%): คำสั่ง SQL ใน Summary Process มี
/*+ PARALLEL(2) */Hint ฝังอยู่ ทำให้ Parallel Degree กินพิกัด CPU 2 Core ที่มีอยู่จนเต็มขีดจำกัด - ขาดการ Maintenance อย่างสม่ำเสมอ: ทำให้ Automated Job ต้องใช้เวลาทำงานนานเกินปกติ หนุนให้ปัญหาการชนกันรุนแรงขึ้น
- Schedule Tuning: หลีกเลี่ยงไม่ให้ Process หลักทำงานทับซ้อนช่วง Default Maintenance Window ของ Oracle (จ.–ศ. 22:00–02:00 น.) เพื่อลดการแย่ง CPU
- Resource Manager Tuning: กำหนด Resource Plan ใหม่ให้ LIC Process ดึง CPU ได้เต็ม 100% แทนที่จะถูกจำกัดไว้ที่ 70%
- Parallel Hint Optimization: ทดสอบถอด
PARALLEL Hintออก หรือปรับ SQL ให้เหมาะสมกับ 2 CPU ที่มีอยู่ หากจำเป็นต้องใช้ Parallel จริงๆ ควรพิจารณาเพิ่ม CPU หรือเปลี่ยนเป็น RAC หลังจากบำรุงรักษาระบบเรียบร้อยแล้วเท่านั้น - Proactive Maintenance: ดูแลระบบอย่างสม่ำเสมอโดย DBA จะช่วยลดระยะเวลาการทำงานของ Automated Job ได้อย่างมาก
ในการวิเคราะห์เชิงลึก เราใช้สมการ: DB time = DB CPU time + DB wait time เพื่อพล็อตพิกัดบนกราฟ และเลือกกลยุทธ์การแก้ไขได้อย่างแม่นยำ:
การประเมินระบบผ่านกราฟ — มาตรฐานการทำงานของ VT Technology
การประเมินสถานะผ่านกราฟนี้ช่วยให้ลูกค้าแก้ปัญหา Database ได้ตรงจุด ลดความสูญเสียจาก Downtime และประหยัดงบประมาณการขยายฮาร์ดแวร์ที่ไม่จำเป็นได้อย่างมีประสิทธิภาพ
จูนระบบฐานข้อมูล Digital Content — เมื่อตารางเดียวสะสมธุรกรรมหลายปีจนตีบตัน
บทนำ: ตาราง Transaction เดียว สะสมข้อมูลเกินหลายปีโดยไม่เคย Purge
ระบบฉากหลักของผู้ให้บริการ Digital Content บนมือถือ (ระบบ API Gateway ที่รับส่งการชำระเงินและ Content Delivery) เกิดอาการช้าลงเรื่อยๆ จากการวิเคราะห์ AWR Report ทีมพบว่าตัวการ Logical Reads สูงถึง 707 ล้าน Block ต่อ session เพียง 6 ชั่วโมง
AWR Snapshot ช่วง 6 ชั่วโมง ระบบใช้ CPU ไป 23.91% แต่ SQL Elapsed Time ไปถึง 78.21% ของ DB Time ทั้งหมด จากการวิเคราะห์ Segment พบว่า:
- PN_DISTRIBUTION_CONTENT (88.92%): ตารางเดียวกิน Logical Reads ไปถึง 628 ล้าน Block (จาก 707 ล้านทั้งหมด) เป็นตาราง Reference จำนวนมากแต่ไม่เคยมี Index
- PN_KIKU_API_DB (5.47%): ตาราง Transaction หลัก มีข้อมูลสะสมตั้งแต่ปี 2013 โดยไม่เคยลบส่วนเก่าออก Index ที่มีอยู่ยังเป็นแบบ Global ทำให้ Partition Pruning ไม่เกิดขึ้น
ทีมตรวจสอบโครงสร้างตารางและ Index แล้วพบปัญหา 2 จุด:
- Step 1 — เปลี่ยน Global Index เป็น Local Partition Index: สร้าง Index ใหม่สำหรับตาราง Transaction โดยเพิ่ม keyword
LOCALท้ายคำสั่ง CREATE INDEX ทำให้ Oracle Optimizer เลือกอ่านเฉพาะ Partition ที่ตรงกับ Condition ได้ (Partition Pruning) ลด Logical Reads ได้อย่างมหาศาล - Step 2 — ย้ายข้อมูลผ่าน Database Link: สร้าง Procedure ย้ายข้อมูลเก่า (มากกว่า 3 ปี) ออกไปเก็บไว้ในเครื่องสำรองแยกต่างหาก (ผ่าน Database Link) หรือ Export เป็น Dump file สำรองไว้ก่อนลบ
- Step 3 — Drop Partition ข้อมูลเก่า: ใช้คำสั่ง
ALTER TABLE ... DROP PARTITIONลบข้อมูลตั้งแต่ปี 2015 ออกจากตารางหลัก สามารถทำได้แบบ Online โดยไม่ต้องหยุดระบบ - Step 4 — ตั้ง Automated Archiving Job: สร้าง Scheduler Job (
DBMS_SCHEDULER) ให้ย้ายข้อมูลเก่าออกอัตโนมัติทุกวันเวลา 01:00 น. เพื่อรักษาขนาดตารางให้อยู่ในระดับที่เหมาะสมตลอดไป
Partition Table โดยไม่มี Local Index เทียบกับไม่ได้ Partition เลย
สิ่งที่สำคัญที่สุดของการออกแบบ Partition Table คือการให้ Index เป็นแบบ LOCAL เสมอ เพื่อให้ Oracle สามารถทำ Partition Pruning อ่านเฉพาะ Partition ที่จำเป็นได้ แทนที่จะสแกนทุก Partition นอกจากนี้ การวางแผน Data Lifecycle Management ที่ดี ด้วยการ Archive และ Drop Partition อย่างสม่ำเสมอ จะช่วยรักษาประสิทธิภาพให้ระบบยืนยาวได้อย่างยั่งยืน
วิเคราะห์และปรับจูน SGA/PGA ระบบงานการบิน — เมื่อ Memory Advisor ชี้จุดที่ค้างให้ได้ชัดเจน
บทนำ: เครื่อง 64 CPU แต่ตั้งค่า Memory ไว้เพียง 32MB
ระบบงานหลักของหน่วยงานด้านการบินใช้ Oracle 9i Enterprise Edition บนเครื่องเซิร์ฟเวอร์ 64-bit ที่มี CPU ถึง 64 Core แต่ค่า pga_aggregate_target ถูกตั้งไว้เพียง 32MB และ Buffer Cache เพียง 144MB จาก SGA Max 462MB — เทียบไม่ได้สัดส่วนกับขนาดของเครื่องเลย
ระบบเกิดอาการ I/O สูงผิดปกติ Query ทำงานช้าลง จากการวิเคราะห์ผ่าน v$db_cache_advice พบว่าที่ Buffer Cache ปัจจุบัน 144MB นั้น Physical Read Factor สูงถึง 24.7× เมื่อเทียบกับขนาดที่เหมาะสม (ที่ 96-112MB ก็ลดลงเหลือ 3.5× และ 1.5× ตามลำดับ)
ทีมรัน Memory Advisor ของ Oracle (ผ่าน v$db_cache_advice และ v$pga_target_advice) และพบปัญหาชัดเจน 2 จุด:
db_cache_size = 144MB ทำให้ Oracle ต้องอ่าน Disk บ่อยมาก Buffer Cache Advice ชี้ว่าถ้าเพิ่มเป็น 96-112MB จะลด Physical Read ได้ถึง 3-7× (แต่ตั้งไว้น้อยเกินไป)pga_aggregate_target = 32MB เล็กเกินไปมาก ทำให้ Sort/Hash Join ต้อง Spill ลง Temp Disk บ่อย เกิดเป็น One-pass/Multipass executions แทน Optimal- Step 1 — สำรวจ Buffer Cache Advice (
v$db_cache_advice): พิจารณา ESTD_PHYSICAL_READ_FACTOR ที่ขนาด 96-112MB ลดลงเหลือ 3.5× จาก 144MB (ขนาดปัจจุบัน) — เป็นจุด Sweet Spot ที่คุ้มค่าที่สุด - Step 2 — ปรับ
pga_aggregate_target: เพิ่มค่าจาก 32MB เป็นค่าที่เหมาะสมกับขนาดเครื่อง (Oracle แนะนำให้ใช้ 20% ของ Physical Memory หรือตามค่า ESTD_OPTIMAL_EXECUTIONS จากv$pga_target_advice) - Step 3 — จัด SGA ใหม่: ลด java_pool_size จาก 112MB ลง (ระบบไม่ใช้ Java) และนำพื้นที่ไปเพิ่ม Buffer Cache ให้อยู่ในช่วง 200-250MB เพื่อประสิทธิภาพที่ดีที่สุดตามคำแนะนำของ Advisor
ไม่จำเป็นเดาสุ่ม — เปิด Advisor แล้ววิเคราะห์ก่อนปรับค่า
Oracle มีเครื่องมือ Memory Advisor ติดตั้งมาให้ฟรี (v$db_cache_advice, v$pga_target_advice, v$shared_pool_advice) ก่อนปรับค่าใดๆ ควรวิเคราะห์ข้อมูลจาก Advisor เหล่านี้เสมอเพื่อให้แน่ใจว่าการเพิ่มค่า Memory จะช่วยเรื่องคุ้มค่าจริง ไม่ใช่การเดาสุ่มแบบไร้ทิศทาง
วิเคราะห์ปัญหาคอขวดระบบ CRM — Lock Contention และ Redo I/O ดูดบานสังหารัมทั้ง 62%
บทนำ: AWR Compare Period เผยข้อมูลเปรียบเทียบ 2 ช่วงเวลา ชี้ตนตอปัญหาได้ชัดเจน
ระบบ CRM ขององค์กรขนาดใหญ่เกิดความช้าลงอย่างมีนัยสำคัญ ครั้งนี้ใช้เครื่องมือทั้ง AWR Report และ AWR Compare Period เปรียบเทียบช่วงเวลาปกติ (12 Feb) กับช่วงที่ยุ่ง (13 Feb) เพื่อไล่เรียงต้นตอปัญหาอย่างแม่นยำ
จาก AWR Compare Period เปรียบช่วงปกติ (12 ก.พ.) กับช่วงยุ่ง (13 ก.พ.) พบความแตกต่างชัดเจน:
| Event | ช่วงปกติ (%) | ช่วงยุ่ง (%) |
|---|---|---|
| CPU time | 72.60% | 27.02% ↓ |
| enq: TM - contention | — | 61.98% ↑↑↑ |
| log file sync | 17.48% | 5.71% |
| log file parallel write | 10.55% | 3.50% |
ตัวร้ายหลัก: ในช่วงปกติ CPU ใช้ 72% (สูงสุด) แต่ช่วงยุ่ง CPU เหลือแค่ 27% เพราะ enq: TM contention ดูดเวลาไปถึง 62% แสดงว่า Session ตัวหนึ่งกำลังล็อก Table อยู่ ทำให้ Session อื่นๆ ทำงานไม่ได้
enq: TM - contention คือสัญญาณว่ามี Session หนึ่งทำ DML บน Table ที่ไม่มี Foreign Key Index ทำให้ Oracle ต้อง Lock ทั้ง Table แทนที่จะ Lock แค่บาง Row อย่างที่ควรจะเป็นlog file sync avg wait 26ms/Commit เพราะ Redo Log File อาจเล็กเกินไปหรือ disk I/O ช้า ทำให้ Commit ปล่อย Session ช้า- แก้ปัญหา TM Contention — สร้าง Index บน Foreign Key: ใน Oracle ถ้า Child Table ไม่มี Index บน Foreign Key Column Oracle จะต้อง Lock ทั้ง Table เมื่อ Parent Row ถูกแก้ไข วิธีแก้ไขคือสร้าง
CREATE INDEXบน FK Column ใน Child Table ทุกตารางที่เกี่ยวข้อง - แก้ปัญหา log file sync — ปรับ Redo Log: ตรวจสอบขนาด Redo Log File (ควรใหญ่กว่าปริมาณ Redo ใน 15-20 นาที) และชักนำ Redo Log Files ไปไว้บน Disk / Volume ที่เร็วโดยเฉพาะ หรือพิจารณาใช้
COMMIT_WAITและCOMMIT_LOGGING(ถ้า consistency ยอมรับได้) - ใช้ AWR Compare Period เป็นเครื่องมือยืนยันผล: หลังปรับค่าแล้ว ใช้เครื่องมือ Compare Period เปรียบเทียบช่วงก่อน-หลังแก้ไข เพื่อยืนยันว่าปรับได้ผลจริงและไม่เกิด Regression ใด
TM Contention มักซ่อนอยู่ สาเหตุหลัก: Foreign Key ไม่มี Index
ใน Oracle ถ้า Child Table ปราศจาก Foreign Key Column หาก DML ใน Parent Table เกิดขึ้น Oracle จะ Lock Table-level บน Child Table ทั้งหมด แทนที่จะ Row-level lock เพียงบาง Row ทำให้ทุก Session ที่พยายแตะ Child Table ต้อง Wait การแก้ไขง่ายด้วยการสร้าง CREATE INDEX ... ON child_table(fk_column) จะช่วยลด TM Contention ได้อย่างมาก
วิเคราะห์ Oracle RAC 2-Node ระบบโลจิสติกส์ — Streams Capture และ Backup ดูด I/O จนระบบหน่วง
บทนำ: RAC 2-Node แต่แต่ละ Node มีปัญหาคนละชุด
ระบบหลักของบริษัทด้านโลจิสติกส์/เดินเรือใช้ Oracle RAC 2-Node เพื่อ High Availability แต่ระบบเพิ่มความช้าลงอย่างต่อเนื่อง จากการวิเคราะห์ AWR ทั้ง 2 Instance พบว่าแต่ละ Node มีปัญหาคนละชุด ทำให้ระบบช้าลงมากกว่าที่ควร
เปรียบ AWR ทั้ง 2 Instance ในช่วงเดียวกัน พบปัญหาคนละชุด:
| Event | Node 1 (%) | Node 2 (%) |
|---|---|---|
| CPU time | 28.5% | 37.4% |
| db file sequential read | 17.0% | 16.4% |
| Streams capture: waiting for archive log | 6.4% | — |
| Backup: sbtwrite2 | — | 6.1% |
| gc cr block busy / gc current block | 1.4% | 2.6% |
ปัญหาทั้ง 2 Node เกิดปัญหาด้าน I/O ต่างไม่เกี่ยวกัน — Node 1 จาก Streams Process ค้างบน Archive Log ในช่วงที่ระบบผลิต และ Node 2 จาก Backup กำลังวิ่งแย่งกับ I/O สำหรับ Workload ปกติ
gc cr block busy และ gc current block 2-way พบทั้ง 2 Node สะท้อนว่ามี Data ถูกรับส่งผ่าน Interconnect สูง Interconnect Traffic 10,513 KB/s บ่งชี้ว่า Hot Block ถูก Access ผิดปกติ- Node 1 — ปรับ Streams Capture: เพิ่มจำนวน Archive Log (หรือเส้น
LOG_ARCHIVE_DESTให้เพียงพอ สำหรับ Streams Capture) เพื่อไม่ให้ Capture Process ต้องรอ Archive Log ที่ถูก Delete ไปก่อนกำหนด หรือสร้าง Standby ที่ Capture เร็วขึ้น - Node 2 — ย้าย Backup ออกนอกช่วง Production: เลื่อน Backup Job ไปทำในช่วง Off-Peak (เช่น ตี 1-5 น.) เพื่อไม่แย่ง I/O กับงาน Production หรือใช้การควบคุม I/O Priority เพื่อให้ Backup กระทบน้อยที่สุด
- Both Nodes — ตรวจสอบ Hot Block: วิเคราะห์ gc block events ด้วย ASH (Active Session History) เพื่อหาว่า Block/Segment ไหนถูก Access จากหลาย Session พร้อมกัน และพิจารณาใช้ Sequence Caching หรือ Row Ordering ลด Interconnect Contention
การ Tune RAC ต้องดู AWR ทุก Instance — ไม่ใช่แค่ Instance เดียว
ในระบบ RAC ปัญหามักพบว่า แต่ละ Node มีตัวร้ายคนละชุด การดูแค่ AWR ของ Node หลักอย่างเดียวอาจพลาดปัญหาสำคัญได้ โดยเฉพาะ Streams/Replication ควรจัดประเภท Node ให้ชัดเจน และ Backup Job ควรแยกวิ่งในช่วง Off-Peak เสมอ
ตาราง AUD$ ทำระบบชำระเงินช้า — เมื่อเปิด DB Auditing ที่คนลืม Purge
บทนำ: AWR ชี้ว่าตาราง System กิน Physical Read มากกว่า Business Table
ระบบชำระเงินแห่งหนึ่งใช้ Oracle 11g บน HP-UX 64-bit เกิดอาการช้าลงโดยไม่มีสาเหตุชัดเจน จาก Segment Stats ใน AWR พบว่าตาราง AUD$ (Oracle Audit Trail) ที่ไม่ใช่ Business Table เลย กลับกิน Physical Read ไปถึง 33.72% ของทั้งหมด
จาก AWR Report ช่วงเช้า (4 ชั่วโมง) พบว่า Physical Reads สูง 1,516 ครั้ง/วินาที เมื่อเจาะ Segment Stats พบว่า:
| ตาราง | Physical Reads | %Total |
|---|---|---|
| SYS.AUD$ (SYSAUX) | 7,373,362 | 33.72% |
| CATPOS.RECEIPT | 7,104,510 | 32.49% |
| CATPOS.ACCOUNT | 5,502,902 | 25.17% |
| CATPOS.CONTRACT | 1,397,022 | 6.39% |
AUD$ สูงกว่า Business Table หลัก! นั่นหมายความว่าการตรวจสอบสิทธิ์ (DB Audit) ทำให้เกิดงาน I/O สูงแบบไม่คาดคิด
- Step 1 — Purge AUD$ ทันที: บันทึกข้อมูลเก่าออกไป จากนั้น Truncate หรือใช้
DBMS_AUDIT_MGMT.CLEAN_AUDIT_TRAILลบบันทึกเก่าออกอย่างสม่ำเสมอ (Scheduled Purge) - Step 2 — จำกัด Audit Scope: ตรวจสอบว่าต้อง Audit อะไรบ้าง ใช้
NOAUDITสำหรับ Operation ที่ไม่จำเป็นต้องตรวจสอบ หรือเปลี่ยนไปเขียน Audit ลง OS File (AUDIT_TRAIL=OS) แทนตาราง - Step 3 — ย้าย AUD$ ออกจาก SYSAUX: ใช้
DBMS_AUDIT_MGMT.SET_AUDIT_TRAIL_LOCATIONย้าย AUD$ ไปไว้ประเภท Tablespace แยกต่างหาก (Oracle 11g+) เพื่อไม่กระทบ SYSAUX
AUD$ คือจุดบอดที่หลาย DBA มักมองข้าม
เมื่อ AWR ชี้ว่า SYSAUX ติดอันดับ Hot Segment สิ่งแรกที่ควรตรวจสอบคือ AUD$ การเปิด DB Audit โดยไม่ระบุ Scope และไม่มีการ Purge อย่างสม่ำเสมอ สามารถทำให้ระบบช้าแบบสืบหาสาเหตุไม่ได้เลย
วิเคราะห์ Oracle RAC ระบบ Radius ของผู้ให้บริการ Internet — log file sync ดูด 38% + Backup ชน Production
บทนำ: Redo 269,000 Bytes/วินาที แต่ Redo Log ไม่ได้รับการปรับจูน
ระบบ Radius Authentication สำหรับ Internet Service Provider (ISP) ใช้ Oracle RAC 2-Node ช่วง Peak พบว่าระบบช้าลงอย่างรุนแรง AWR ชี้ว่า Redo size สูงถึง 269,681 Bytes/วินาที และ log file sync ใช้เวลา 38.3% ของ DB Time ทั้งหมด
| Event | % DB Time | Avg Wait |
|---|---|---|
| log file sync | 38.3% | 10 ms |
| CPU time | 24.8% | — |
| Backup: sbtbackup | 17.3% | 219,092 ms (!) |
| Backup: sbtwrite2 | 12.9% | 4 ms |
| gc current block 2-way | 12.2% | 1 ms |
น่าตกใจที่สุด: Backup sbtbackup มี Avg Wait สูงถึง 219 วินาทีต่อครั้ง เลย แสดงว่า Tape/SBT ตอบสนองช้ามาก
- Step 1 — เพิ่มขนาด Redo Log File: คำนวณจาก Redo Size (269K/s) ควรปรับเป็น Redo Log ที่ใหญ่พอกับปริมาณ Redo ใน 15-20 นาที เพื่อลด Log Switch และลดความถี่ของ LGWR
- Step 2 — พิจารณา Batch Commit: สำหรับระบบ OLTP ที่ Commit ทุก row พิจารณาปรับแอปพลิเคชันให้ Commit เป็นชุด (Batch) เพื่อลด Redo flush ต่อครั้ง หรือใช้
COMMIT_WRITEแบบ Asynchronous - Step 3 — ย้าย Backup ออก Off-Peak: Tape Avg Wait 219 วินาทีคืออันตรายเกินไป เลื่อน Backup Job ออกสู่ช่วง Off-Peak หรือใช้ Disk Staging แทน Tape โดยตรง และค่อยโอนไป Tape ภายหลัง
log file sync คือสัญญาณที่ LGWR ต้องทำงานหนักเกินไป
เมื่อ log file sync สูงให้ตรวจสอบ 3 สิ่งพร้อมกัน: (1) Redo size สูงเกินไป ควรปรับ Redo Log ให้ใหญ่ขึ้น (2) Disk I/O ช้า ย้าย Redo Log ไป Disk ที่เร็วขึ้น (3) Commit บ่อยเกินไป ปรับ Application ให้ Batch Commit
กู้ระบบงานตุลาการหยุดชะงัก — จากข้อจำกัด Datafile 32GB
บทนำ: ระบบงานสำคัญของรัฐหยุดกะทันหัน ไม่ใช่เพราะฮาร์ดแวร์พัง
เมื่อระบบของหน่วยงานราชการล่ม ทุกวินาทีมีความหมาย นี่คือเหตุการณ์ Incident Support ฉุกเฉินที่ทีมที่ปรึกษาได้รับสายด่วน เพราะระบบงานหลักทั้งหมดไม่สามารถบันทึกข้อมูลใหม่ได้ ทั้งที่เซิร์ฟเวอร์ยังทำงานอยู่ปกติ
ทาง Vendor ผู้ดูแลระบบให้กับหน่วยงานด้านตุลาการ ติดต่อขอความช่วยเหลือด่วน เนื่องจากแอปพลิเคชันระบบงานหลักเกิดการหยุดชะงัก ไม่สามารถบันทึกทรานแซกชันใหม่ลงในฐานข้อมูลได้เลย ส่งผลให้การปฏิบัติงานของเจ้าหน้าที่สะดุดลงอย่างสิ้นเชิง
ทีมที่ปรึกษา Remote เข้าสู่ระบบ Linux เพื่อตรวจสอบ Oracle Database Log ทันที พบว่าสาเหตุไม่ใช่ Hardware หรือ Network แต่เป็นปัญหาโครงสร้างการจัดเก็บข้อมูลที่สะสมมานาน:
เพื่อให้ระบบกลับมาให้บริการได้เร็วที่สุด ทีมงานดำเนินการแก้ไขปัญหาเฉพาะหน้าอย่างเร่งด่วน:
- Add Datafile ไฟล์ใหม่เข้า Tablespace เดิม: ใช้คำสั่ง
ALTER TABLESPACE ... ADD DATAFILEเพิ่ม Datafile ใหม่เข้าไปใน Tablespace ที่เต็มอยู่ เปิดพื้นที่จัดเก็บใหม่ให้ระบบทำงานต่อได้ทันที - Online Operation — Zero Downtime: กระบวนการทั้งหมดสามารถทำได้แบบ Online โดยไม่ต้องหยุด Database แม้แต่วินาทีเดียว ทำให้ระบบกลับมาบันทึกข้อมูลได้อย่างรวดเร็วโดยไม่กระทบการให้บริการ
2 มาตรการป้องกันที่ต้องทำก่อนประวัติศาสตร์ซ้ำรอย
1. Database Monitoring & Alert: ตั้งค่าแจ้งเตือนเมื่อ Datafile / Tablespace ถูกใช้งานถึง 80–90% เพื่อเพิ่มพื้นที่ได้ล่วงหน้า ก่อนจะถึงเพดาน
2. Tablespace Segregation: แยก Tablespace ตามกลุ่มข้อมูล หรือแยก Data / Index อย่างชัดเจน ลดความเสี่ยงที่ข้อมูลกลุ่มหนึ่งจะกระทบทั้งระบบ และง่ายต่อการบริหารจัดการ I/O
กู้คืนระบบสำรองฉุกเฉิน (DR) ขาดการเชื่อมต่อ — หน่วยงานด้านการเดินทางและคมนาคม
บทนำ: เมื่อสายป้องกันภัยขาดช่วงเพราะไฟล์หาย
ระบบ DR ที่ดูเหมือนทำงานปกติอาจซ่อนความเสี่ยงไว้โดยไม่รู้ตัว เพราะข้อมูลบนเครื่อง DR ไม่ได้อัปเดตตามเครื่องหลักอยู่เรื่อยๆ หากต้องสลับมาใช้ DR จริงๆ ข้อมูลที่บันทึกใหม่หลายชั่วโมงหรือหลายวันจะหายไป
ระบบแจ้งเตือนรายงานว่าสถานะของฐานข้อมูลระหว่าง DC และ DR Site ไม่ทำการ Sync ถึงกันเป็นระยะเวลาหนึ่ง ข้อมูลบนเครื่อง DR ไม่อัปเดตตามเครื่องหลัก ทำให้เกิดความเสี่ยงสูงหากต้องสลับไปใช้งาน DR Site จริง
ทีมที่ปรึกษาตรวจสอบ Log file และสถานะ Standby Database แล้วพบสาเหตุชัดเจน:
- Log Sequence ขาดตอน: มีไฟล์ Archive Log บางส่วนสูญหายไประหว่างทาง (Missing Archive Log) ทำให้ Sequence ต่อเนื่องยังไม่ครบ
- การทำงานของ Standby: ระบบต้องอ่าน Archive Log ตามลำดับ Sequence อย่างต่อเนื่อง เมื่อไฟล์ใดไฟล์หนึ่งแหว่งหาย กระบวนการ Apply Log บนเครื่อง DR จะหยุดชะงักทันที ไม่สามารถข้ามไปอ่านไฟล์ลำดับถัดไปได้
- สาเหตุของการสูญหาย: อาจเกิดจาก Network สะดุดชั่วคราว, พื้นที่จัดเก็บเต็มแล้วระบบ Auto-delete ลบไฟล์ทิ้งก่อนส่ง, หรือความผิดพลาดระดับ OS — เมื่อไฟล์ถูกลบออกจากเครื่อง DC แล้ว DR จึงไม่สามารถไล่ตามได้อีกต่อไป
เนื่องจากไฟล์ Archive Log ที่หายไปไม่สามารถกู้คืนได้แล้ว ทีมงานดำเนินการ Rebuild DR Site ใหม่ทั้งหมด:
- Step 1 — Stop DR Sync: หยุดโปรเซส Standby บนเครื่อง DR ชั่วคราวเพื่อเตรียมการสร้างใหม่
- Step 2 — Database Cloning: สำรองข้อมูล (Backup) จากเครื่อง DC ในสถานะปัจจุบัน แล้วนำมาโคลน (Clone) สร้างฐานข้อมูลบนเครื่อง DR ใหม่ทั้งหมด (Re-instantiate) ให้ด้านข้อมูลตรงกับเครื่องหลัก ณ แนวเวลานั้นเป็นต้น
- Step 3 — Re-establish Synchronization: ตั้งค่า Standby Control File ใหม่ และเปิดการทำงาน Apply Log ให้กลับมาทำงานตามปกติ
- Step 4 — Verification: ตรวจสอบความถูกต้องของ Log Sequence ยืนยันว่าเครื่อง DR สามารถ Sync ข้อมูลตามเครื่อง DC ได้อย่างต่อเนื่องแบบ Real-time
ระบบ DR ที่ไว้ใจได้ต้องมีการตรวจสอบอย่างใกล้ชิด
1. ปรับ Policy การลบ Archive Log: ต้องมั่นใจว่าไฟล์จะถูกลบ ก็ต่อเมื่อถูกส่งและ Apply ลงบนเครื่อง DR เรียบร้อยแล้วเท่านั้น (เช่น RMAN DELETE ARCHIVELOG ... BACKED UP ... TO)
2. เพิ่ม Monitoring Lag Time: ติดตั้งระบบแจ้งเตือนตรวจสอบความหน่วง (Lag Time) และความสมบูรณ์ของการส่ง Archive Log อย่างใกล้ชิด เพื่อตรวจพบความผิดปกติได้ทันที ก่อนที่ไฟล์จะถูกลบทิ้งไป
แก้วิกฤตระบบโรงงานสะดุด — SYSAUX Tablespace เต็มจาก Audit Log สะสมเกินสัดส่วน
บทนำ: เมื่อนโยบายความปลอดภัยกลายเป็นตัวสร้างปัญหาเอง
ระบบ Audit Log ถูกออกแบบมาเพื่อความปลอดภัย แต่เมื่อแอปพลิเคชันใช้ DDL พร่ำเพรือ ไฟล์ Audit เหล่านั้นก็สะสมจนเต็มพื้นที่โดยไม่รู้ตัว ทำให้ระบบหยุดชะงักกะทันหัน
ระบบฐานข้อมูลหลักของโรงงานเกิดปัญหาขัดข้องกะทันหัน (Database Hang) ไม่สามารถประมวลผลทรานแซกชันหรือทำงานต่อได้เลย ส่งผลกระทบต่อสายการผลิตโดยตรง จากการตรวจสอบ Log เบื้องต้นพบว่าสาเหตุเกิดจาก SYSAUX Tablespace เต็มขีดจำกัด 32 GB
ทีมที่ปรึกษาตรวจสอบเชิงลึกว่าทำไม SYSAUX จึงเต็มอย่างรวดเร็วผิดปกติ และพบต้นตอคือพฤติกรรมของแอปพลิเคชัน:
CREATE และ DROP TABLE ชั่วคราวซ้ำแล้วซ้ำเล่าในกระบวนการทำงานภายใต้ข้อจำกัดที่ลูกค้ายังรอ Patch จากบริษัทแม่ และไม่สามารถยกเลิก Audit Log ได้เนื่องจาก Compliance ทีมงานเลือกวิธีแก้ไขที่เหมาะสมที่สุด:
- Add Datafile เข้า SYSAUX Tablespace: ใช้คำสั่ง
ALTER TABLESPACE SYSAUX ADD DATAFILEเพิ่มไฟล์ Datafile ใหม่เข้าไปโดยตรง ขยายความจุของพื้นที่จัดเก็บโดยตรง - Online, Zero Downtime: การดำเนินการทำได้แบบ Online โดยไม่ต้องหยุด Database สายการผลิตกลับมาเดินหน้าได้ทันที
- คงนโยบาย Audit Log ไว้ครบถ้วน: ระบบยังเก็บบันทึก Audit Log ตาม Compliance ได้อย่างสมบูรณ์ระหว่างรอการแก้ไขโค้ดถาวร
แก้ที่ต้นเหตุของ Application คือทางออกที่ยั่งยืนที่สุด
1. Application Tuning (Global Temporary Table): ประสานงานกับบริษัทแม่เพื่อเปลี่ยนจากการใช้ CREATE/DROP TABLE พร่ำเพรือ ไปใช้ Global Temporary Table (GTT) แทน ช่วยลด Audit Log และ Redo Log ที่ไม่จำเป็นได้อย่างมหาศาล
2. Audit Log Housekeeping: ตั้งเวลา Purge ข้อมูล Audit Log ที่เก่าเกินความจำเป็นทิ้งอย่างเป็นระบบ โดยใช้แพ็กเกจ DBMS_AUDIT_MGMT คืนพื้นที่ว่างให้ระบบ และควบคุมไม่ให้ SYSAUX บวมจนควบคุมไม่ได้อีก
ระบบงานไอทีหรือฐานข้อมูลในองค์กรของคุณกำลังประสบปัญหาเหล่านี้?
ทีมงานผู้เชี่ยวชาญของ VT Technology ยินดีช่วยเหลือ ตรวจสอบ จูนนิ่งแก้ไข และวางมาตรการด้านความปลอดภัยและการสำรองข้อมูลให้องค์กรของคุณทำงานได้อย่างปลอดภัย 24x7
📝 ติดต่อวิเคราะห์ปัญหาระบบฟรี