Oracle Database Performance Tuning Methodology

💡 ทำไมต้องทำ (เหตุผลและประสบการณ์หน้างาน):

Oracle Database แต่ละระบบมีสภาพแวดล้อมไม่เหมือนกัน บางระบบเป็น Standard Edition บางระบบเป็น Enterprise Edition บางระบบเป็น Single Instance ขณะที่บางระบบใช้ RAC, Data Guard, ASM หรือ SAN เครื่องมือและแนวทางที่ใช้จึงไม่สามารถนำมาใช้เหมือนกันทุกระบบได้ การสำรวจสภาพแวดล้อมก่อนเริ่มงานช่วยให้เราทราบว่าเครื่องมือใดใช้ได้ ข้อจำกัดอยู่ตรงไหน และการเปลี่ยนแปลงใดอาจกระทบระบบ

นอกจากนี้ ปัญหาที่ลูกค้าแจ้งว่า “ฐานข้อมูลช้า” บางครั้งไม่ได้เกิดจาก Database โดยตรง แต่อาจเกิดหลังจากเปลี่ยน Server, เพิ่ม RAM, ย้าย Storage, อัปเกรดระบบ หรือมี Batch Job ใหม่ การสอบถามประวัติและตรวจสอบการเปลี่ยนแปลงล่าสุดจึงช่วยลดเวลาในการค้นหาสาเหตุได้มาก

💡 ทำไมต้องทำ (เหตุผลและประสบการณ์หน้างาน):

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

การดู AWR หรือ Statspack ตั้งแต่ต้นช่วยให้เราตอบคำถามนี้ได้อย่างรวดเร็ว เพราะรายงานจะแสดงให้เห็นว่า Database ใช้เวลาไปกับงานประเภทใด SQL ใดใช้ทรัพยากรมาก และระบบกำลังรออะไรอยู่

ขั้นตอนนี้ต้องทำก่อนการปรับ Parameter, Gather Statistics หรือ Rebuild Index เนื่องจากการเปลี่ยนแปลงเหล่านั้นอาจทำให้พฤติกรรมของระบบเปลี่ยนไป แม้ระบบอาจเร็วขึ้น แต่หลักฐานที่ใช้ระบุต้นเหตุเดิมก็อาจหายไป ทำให้ไม่สามารถอธิบายกับลูกค้าได้อย่างชัดเจนว่าปัญหาเกิดจากอะไรและแก้ไขด้วยวิธีใด

💡 ทำไมต้องทำ (เหตุผลและประสบการณ์หน้างาน):

จากประสบการณ์หน้างาน ปัญหาที่พบได้บ่อยมากคือ Oracle ใช้ RAM น้อยกว่าที่ Server มีอยู่จริง

กรณีแรกคือระบบที่ติดตั้งแบบ Typical Installation แล้วใช้ค่าที่ระบบกำหนดมาให้ต่อเนื่อง โดยไม่มี DBA เข้ามาปรับแต่งเพิ่มเติม ในหลายระบบ Oracle อาจได้รับ RAM เพียงประมาณ 40% ของหน่วยความจำที่ติดตั้งอยู่ แม้เครื่องจะยังมี RAM เหลืออีกมาก

อีกกรณีที่พบเป็นประจำคือ ลูกค้าเพิ่ม RAM ให้ Server ในภายหลัง แต่ไม่มีผู้ปรับค่า SGA และ PGA ของ Oracle ตาม RAM ที่เพิ่มขึ้น Oracle จึงยังใช้หน่วยความจำเท่าเดิม แม้ Hardware จะได้รับการอัปเกรดแล้วก็ตาม จากระบบที่เข้าไปตรวจสอบจริง พบลักษณะนี้ในสัดส่วนสูงมาก จึงเป็นเหตุผลที่เราตรวจสอบ Memory Configuration ในช่วงต้นของงาน

เมื่อ Oracle ได้รับ RAM น้อยเกินไป ข้อมูลที่ควรเก็บอยู่ใน Buffer Cache จะต้องถูกอ่านจาก Storage ซ้ำ การ Sort และ Hash อาจต้องใช้ Temporary Tablespace มากขึ้น และ Shared Pool อาจไม่เพียงพอสำหรับ SQL ที่ใช้งานประจำ ส่งผลให้ระบบช้า ทั้งที่ Server ยังมีทรัพยากรเหลือ

💡 ทำไมต้องทำ (เหตุผลและประสบการณ์หน้างาน):

Oracle Optimizer ต้องใช้ Statistics เพื่อประเมินจำนวนข้อมูลและเลือก Execution Plan หากข้อมูลสถิติไม่ตรงกับข้อมูลจริง เช่น ตารางมีข้อมูลเพิ่มขึ้นจำนวนมาก แต่ Statistics ยังเป็นข้อมูลเก่า Optimizer อาจเลือก Join Method, Access Path หรือ Index ที่ไม่เหมาะกับปริมาณข้อมูลปัจจุบัน

อย่างไรก็ตาม เราไม่เริ่มงานด้วยการ Gather Statistics ทันที เพราะการเก็บ Statistics ใหม่อาจทำให้ Execution Plan เปลี่ยน และทำให้หลักฐานของปัญหาเดิมหายไป ขั้นตอนนี้จึงดำเนินการหลังจากตรวจสอบรายงาน Performance และทราบแล้วว่า Statistics หรือ Object ใดเกี่ยวข้องกับปัญหา

ในส่วนของ Table และ Index ระบบที่มีการลบ แก้ไข หรือโหลดข้อมูลจำนวนมากเป็นเวลานาน อาจมีพื้นที่ว่างสะสม ใช้พื้นที่มากเกินจริง หรือมีโครงสร้างที่ไม่สอดคล้องกับลักษณะการใช้งาน การตรวจสอบจึงต้องดูเป็นราย Object ไม่ใช่ Rebuild Index ทั้งระบบโดยไม่มีเหตุผลรองรับ

💡 ทำไมต้องทำ (เหตุผลและประสบการณ์หน้างาน):

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

การเพิ่ม RAM หรือ CPU อาจช่วยให้ SQL ดังกล่าวทำงานเร็วขึ้นเพียงเล็กน้อย แต่ไม่ได้แก้ต้นเหตุ หาก SQL ยังอ่านข้อมูลมากเกินความจำเป็น ปัญหาก็จะกลับมาเมื่อข้อมูลหรือจำนวนผู้ใช้งานเพิ่มขึ้น

การวิเคราะห์ Execution Plan ช่วยให้เห็นว่า Oracle อ่านข้อมูลอย่างไร ใช้ Index หรือไม่ Join ตารางในลำดับใด และประมาณจำนวนข้อมูลคลาดเคลื่อนหรือไม่ จากนั้นจึงพิจารณาปรับ SQL, เพิ่ม Index หรือแก้ Execution Plan ตรงจุดที่เป็นปัญหา

💡 ทำไมต้องทำ (เหตุผลและประสบการณ์หน้างาน):

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

เราจึงเปรียบเทียบตัวชี้วัดก่อนและหลัง เช่น Response Time, DB Time, CPU Time, Wait Events และปริมาณงาน เพื่อยืนยันว่าการปรับปรุงช่วยลดภาระของระบบจริง

การตรวจสอบซ้ำยังช่วยค้นหาผลกระทบข้างเคียง เช่น SQL หนึ่งตัวเร็วขึ้น แต่ทำให้ SQL อื่นช้าลง หรือ Wait Event เดิมลดลงแต่มีคอขวดใหม่เกิดขึ้น

💡 ทำไมต้องทำ (เหตุผลและประสบการณ์หน้างาน):

เมื่อลูกค้าพบว่าระบบช้า แนวทางที่ถูกเสนอขึ้นมาบ่อยคือการเพิ่ม RAM, CPU หรือเปลี่ยน Storage แต่หากต้นเหตุเกิดจาก SQL, Execution Plan หรือการตั้งค่าฐานข้อมูล การเพิ่ม Hardware อาจช่วยได้เพียงชั่วคราวและไม่คุ้มค่ากับการลงทุน

เราจึงแยกปัญหาฝั่ง Database ออกจากปัญหาฝั่ง Infrastructure ก่อน เมื่อปรับแต่งฐานข้อมูลแล้วจึงดูข้อมูลระดับ Operating System เพื่อประเมินว่า CPU เต็มจริงหรือไม่ RAM ขาดหรือไม่ Storage มี Latency สูงหรือไม่ และปัญหาเกิดเฉพาะบางช่วงเวลาหรือเกิดตลอดเวลา

แนวทางนี้ช่วยให้คำแนะนำด้าน Hardware มีข้อมูลรองรับ เช่น ต้องเพิ่ม RAM อีกเท่าใด Storage ต้องรองรับ IOPS หรือ Latency ระดับใด หรือคอขวดอยู่ที่ CPU มากกว่า Disk

💡 ทำไมต้องทำ (เหตุผลและประสบการณ์หน้างาน):

ประสิทธิภาพของฐานข้อมูลไม่ได้คงที่ตลอดไป แม้ระบบจะได้รับการปรับแต่งจนทำงานได้ดีแล้ว ปริมาณข้อมูล จำนวนผู้ใช้งาน รูปแบบของ SQL และภาระงานจะเปลี่ยนแปลงอยู่เสมอ

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

จากประสบการณ์หน้างาน ปัญหาหลายอย่างจะมีสัญญาณเตือนล่วงหน้า เช่น:

• SQL บางคำสั่งใช้เวลานานขึ้นทีละน้อย
• CPU หรือ Storage เริ่มใช้งานสูงในบางช่วงเวลา
• Tablespace และ Datafile เติบโตเร็วกว่าปกติ
• Statistics หรือ Maintenance Job ทำงานไม่ครบ
• ปริมาณ Session และ Workload เพิ่มขึ้นต่อเนื่อง
• Wait Events บางประเภทเริ่มสูงขึ้น แม้ผู้ใช้งานยังไม่รู้สึกว่าระบบช้า

การตรวจสอบตามรอบช่วยให้พบแนวโน้มเหล่านี้ก่อนจะพัฒนาเป็นปัญหาใหญ่ และช่วยให้สามารถวางแผนแก้ไขใน Maintenance Window ได้ แทนการแก้ปัญหาแบบฉุกเฉินระหว่างเวลาทำงาน