Case 10 · วิเคราะห์ Oracle จากหลักฐาน

เมื่อ enq: TM - contention เพิ่มเป็น 61.98% ของ DB Time

AWR Compare Period แสดงว่าระบบ CRM เปลี่ยนจากช่วงที่ใช้เวลากับ CPU เป็นหลัก ไปสู่ช่วงที่เวลาส่วนใหญ่หมดกับการรอ DML enqueue บทวิเคราะห์นี้แยกชัดว่า AWR ยืนยันอะไรได้ และสาเหตุใดยังต้องตรวจเพิ่มก่อนเปลี่ยนระบบจริง

ยืนยันจาก AWR Compare Period ปกปิดชื่อระบบและ Object ไม่มีข้อมูลผลหลังแก้ ไม่พบ ORA ที่ยืนยันแล้ว ตรวจทาน Fact Sheet 14 ส.ค. 2569
บทสรุปผู้บริหาร · Executive Summary

บทสรุปสำหรับผู้บริหาร

รายงาน AWR ที่นำมาเปรียบเทียบสองช่วงเวลาพบการเปลี่ยนแปลงของรูปแบบคอขวดอย่างชัดเจน ช่วงแรกมี CPU time 72.60% ของ DB Time แต่ในอีกช่วงหนึ่ง CPU time ลดเหลือ 27.02% ขณะที่ enq: TM - contention เพิ่มขึ้นเป็น 61.98% จึงยืนยันได้ว่า ระบบเสียเวลาส่วนใหญ่ไปกับการรอ lock ประเภท TM ในช่วงดังกล่าว ไม่ใช่การใช้ CPU เพียงอย่างเดียว

อย่างไรก็ตาม AWR ชุดนี้ยังไม่ระบุว่า Object ใดเป็นต้นเหตุ ใครเป็น Blocking Session หรือเกิดจาก Foreign Key ที่ไม่มี Index จริงหรือไม่ ดังนั้นข้อสรุปที่เหมาะสมคือ “พบ TM contention เป็นคอขวดสำคัญ” ไม่ใช่ “พิสูจน์แล้วว่าต้องสร้าง Foreign Key Index”

ความหมายต่อการตัดสินใจ ข้อมูลปัจจุบันยังไม่เพียงพอให้ลงทุนเพิ่มฮาร์ดแวร์ สร้าง Index หรือย้าย Redo Log ทันที งานลำดับแรกคือเก็บ Blocking Session, Object และ SQL ในช่วงเกิดเหตุ เพื่อให้การเปลี่ยนแปลงแก้ตรงสาเหตุและสามารถวัดผลได้
61.98% enq: TM - contention สัดส่วน DB Time ในช่วงที่มีปัญหา · ยืนยันจาก AWR
72.60% → 27.02% CPU time สัดส่วน DB Time ระหว่างสองช่วง · ไม่ใช่ CPU utilization
26 ms Average log file sync ค่าที่บันทึกในรายงาน · ต้องวิเคราะห์ร่วมกับ LGWR และ commit rate
67,926 B/s Redo size ค่าที่บันทึกในรายงาน · ตัวเลขเพียงอย่างเดียวยังไม่พิสูจน์ว่ามากผิดปกติ
ขอบเขตหลักฐาน · Evidence Boundary

หลักฐานบอกอะไร และยังบอกอะไรไม่ได้

ยืนยันแล้ว

  • มีการเปรียบเทียบ AWR สองช่วงเวลา
  • enq: TM - contention อยู่ที่ 61.98% ในช่วงที่มีปัญหา
  • พบ log file sync และ log file parallel write ในทั้งสองช่วง

เป็นไปได้ แต่ต้องตรวจเพิ่ม

  • มี DML บางชุดสร้าง blocking chain
  • Foreign Key ที่ไม่มี Index อาจเกี่ยวข้อง
  • Commit frequency, LGWR scheduling หรือ I/O อาจเกี่ยวกับ log file sync

ยังสรุปไม่ได้

  • Object หรือ SQL ใดเป็น Root Cause
  • Redo Log มีขนาดเล็กเกินไป
  • การสร้าง Index หรือย้าย Disk ได้แก้ปัญหาแล้ว
สถานะผลลัพธ์: ไม่พบ AWR หลังเปลี่ยนแปลงหรือผลทดสอบก่อน–หลัง จึงยังไม่รายงานเปอร์เซ็นต์การปรับปรุงและไม่ใช้คำว่า “แก้สำเร็จ”
แนวทางตรวจสอบ · Safe Next Actions

แนวทางตรวจสอบก่อนเลือกวิธีแก้

  1. ระบุ Blocking Session, Waiting Session, enqueue mode และ Object ที่เกี่ยวข้องในช่วงเวลาเดียวกับเหตุการณ์
  2. เชื่อม Object กับ SQL และลำดับ DML เพื่อดูว่าการรอเกิดจากธุรกรรมใด
  3. ตรวจ Foreign Key และ Index เฉพาะตารางที่หลักฐานชี้ถึง พร้อมตรวจผลกระทบต่อ DML และพื้นที่จัดเก็บ
  4. วิเคราะห์ log file sync ร่วมกับ commit frequency, LGWR scheduling, redo write latency และ log file parallel write
  5. ทดสอบการเปลี่ยนแปลงในสภาพแวดล้อมที่ควบคุมได้ แล้วเปรียบเทียบ AWR ด้วย workload และช่วงเวลาที่เทียบกันได้

ไม่ควรสร้าง Index ให้ Foreign Key ทุกตัวโดยอัตโนมัติ เพิ่มขนาด Redo Log เพื่อแก้ log file sync ทุกกรณี หรือเปิด asynchronous commit โดยยังไม่ได้ประเมินความถูกต้องและความคงทนของธุรกรรม

หลักฐานเชิงเทคนิค · Technical Evidence

รายละเอียดสำหรับ DBA/IT

รายละเอียดทั้งหมดอยู่ใน HTML ของหน้านี้เพื่อให้ค้นหาได้ แต่พับไว้เพื่อลดความยาวสำหรับผู้อ่านทั่วไป

ตาราง AWR Compare Period
Metric/Event ช่วงเปรียบเทียบ A ช่วงเปรียบเทียบ B สถานะ
CPU time 72.60% 27.02% ยืนยันจาก AWR
enq: TM - contention ไม่อยู่ในรายการที่บันทึก 61.98% ยืนยันจาก AWR
log file sync 17.48% 5.71% ยืนยันจาก AWR
log file parallel write 10.55% 3.50% ยืนยันจาก AWR
enq: TM - contention หมายความว่าอะไร

enq: TM - contention เป็นการรอ DML enqueue ที่เกี่ยวข้องกับ Table/Object การพบ Event นี้ใน AWR ยืนยันว่ามี lock contention แต่ AWR ส่วนนี้เพียงอย่างเดียว ยังไม่สามารถระบุ Object, lock mode, Blocking Session หรือเหตุผลที่ lock ถูกถือไว้นานได้

Foreign Key ที่ไม่มี Index เป็นหนึ่งในสาเหตุที่ควรตรวจเมื่อมี DML บน Parent Key แต่ไม่ควรถูกประกาศเป็น Root Cause จนกว่าจะเชื่อมโยง blocker, object และ constraint ได้

log file sync และ log file parallel write

เมื่อ session ทำ COMMIT การรอ log file sync ครอบคลุมเวลาที่รอให้ LGWR flush redo และตอบกลับ session ส่วน log file parallel write เป็นข้อมูลฝั่งการเขียน redo ของ LGWR จึงต้องวิเคราะห์ทั้งสอง Event ร่วมกับ commit rate, I/O latency และ CPU scheduling ของ LGWR

Redo size 67,926 bytes/second ไม่ได้พิสูจน์ว่า Redo Log เล็กเกินไป และขนาด Redo Log มีผลกับความถี่ของ log switch มากกว่าการแก้ทุกสาเหตุของ commit latency

ORA-xxxxx และขอบเขตข้อมูลที่เผยแพร่

หลักฐานที่ตรวจสอบสำหรับ Case นี้ไม่พบรหัส ORA-xxxxx ที่เชื่อมโยงกับเหตุการณ์ จึงไม่เพิ่มรหัส ORA ใดเพื่อ SEO และไม่อ้างว่าลูกค้าพบ Oracle Error หากพบ Alert Log เพิ่มเติมในอนาคต ต้องตรวจเวลาและความสัมพันธ์กับช่วง AWR ก่อนนำมาเพิ่ม

ชื่อองค์กร ระบบ Schema, Table, Constraint, SQL และข้อมูลภายในถูกปกปิด ตัวเลขที่เผยแพร่จำกัดเฉพาะข้อมูลสรุปที่ใช้ทำความเข้าใจพฤติกรรมของระบบ

แหล่งข้อมูลและข้อจำกัด · Sources

แหล่งข้อมูลและข้อจำกัด

  • หลักฐาน Case: AWR Compare Period และ Fact Sheet ที่จัดทำจากเอกสารต้นทางภายใน โดยไม่เผยแพร่ชื่อไฟล์หรือชื่อระบบ
  • ข้อจำกัด: ไม่มี blocking chain, object-level evidence และรายงานหลังเปลี่ยนแปลงในชุดหลักฐานที่ตรวจ
  • คำอธิบาย Wait Event: อ้างอิงความหมายทั่วไปจาก Oracle Database Reference

ระบบของคุณพบ Lock Contention คล้ายกันหรือไม่?

การเห็น enq: TM - contention สูงเป็นจุดเริ่มต้นของการวิเคราะห์ แต่การเปลี่ยนระบบควรเริ่มหลังระบุ blocker, object และ SQL ที่เกี่ยวข้องแล้ว

ปรึกษาการวิเคราะห์ Oracle Performance