Oracle AWR Report: วิเคราะห์ Performance และหา Bottleneck อย่างมืออาชีพ

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

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

Oracle AWR Report คืออะไร? ทำไมถึงสำคัญ?

Oracle Automatic Workload Repository (AWR) คือคุณสมบัติในฐานข้อมูล Oracle ที่ทำหน้าที่รวบรวมและจัดเก็บข้อมูลประสิทธิภาพของฐานข้อมูลในรูปแบบของ “Snapshot” โดยอัตโนมัติ ข้อมูลเหล่านี้ประกอบด้วยสถิติต่างๆ ที่สำคัญ เช่น สถิติของ CPU, I/O, Memory, Wait Events, SQL Statements ที่ใช้ทรัพยากรมากที่สุด และอื่นๆ อีกมากมาย AWR จะสร้าง Snapshot เหล่านี้เป็นระยะๆ (โดยค่าเริ่มต้นทุกๆ 1 ชั่วโมง) และเก็บไว้ในฐานข้อมูล เพื่อให้เราสามารถเรียกดูและเปรียบเทียบข้อมูลในช่วงเวลาต่างๆ ได้

ความสำคัญของ AWR Report อยู่ที่ความสามารถในการ:
* **ระบุปัญหาเชิงรุก (Proactive):** ช่วยให้ DBA สามารถตรวจจับแนวโน้มของประสิทธิภาพที่ลดลงก่อนที่จะกลายเป็นปัญหาใหญ่
* **วินิจฉัยปัญหาเชิงรับ (Reactive):** เมื่อเกิดปัญหาประสิทธิภาพขึ้น AWR Report จะเป็นแหล่งข้อมูลชั้นดีในการวิเคราะห์หาสาเหตุหลักและจุดที่เป็นคอขวด
* **เปรียบเทียบประสิทธิภาพ:** สามารถสร้างรายงานเปรียบเทียบ (AWR Diff Report) ระหว่างช่วงเวลาที่มีประสิทธิภาพดีและช่วงเวลาที่มีปัญหา เพื่อระบุความแตกต่างที่เกิดขึ้น
* **ยืนยันผลการปรับแต่ง:** ใช้ AWR Report เพื่อวัดผลลัพธ์ของการปรับแต่ง (Tuning) ที่ได้ดำเนินการไป ว่ามีประสิทธิภาพดีขึ้นจริงหรือไม่

ข้อควรทราบคือ AWR เป็นคุณสมบัติที่ต้องมีไลเซนส์ Oracle Diagnostic Pack ซึ่งมักจะมาพร้อมกับ Oracle Enterprise Edition ดังนั้น หากคุณใช้ Standard Edition หรือไม่ได้ซื้อไลเซนส์ Diagnostic Pack คุณอาจต้องพึ่งพาเครื่องมืออื่นๆ เช่น STATSPACK (ซึ่งมีความสามารถใกล้เคียงกัน แต่ต้องตั้งค่าและรันด้วยตนเองมากกว่า)

การสร้าง AWR Report: ขั้นตอนและตัวอย่างโค้ด

การสร้าง AWR Report ทำได้ไม่ยากนัก โดยปกติแล้วจะทำผ่าน SQL*Plus หรือ Oracle Enterprise Manager (OEM) สำหรับบทความนี้ เราจะเน้นไปที่การสร้างผ่าน SQL*Plus ซึ่งเป็นวิธีที่ได้รับความนิยมและยืดหยุ่น

ก่อนอื่น คุณต้องเข้าสู่ระบบ SQL*Plus ด้วยสิทธิ์ที่มีบทบาท `SYSDBA` หรือมีสิทธิ์ที่เพียงพอในการเข้าถึงมุมมอง `V$` และ `DBA_HIST_`

ขั้นตอนการสร้าง AWR Report ผ่าน SQL*Plus

1. **ระบุ Snapshot ID ที่ต้องการ:** Snapshot ID คือตัวเลขที่ใช้ระบุช่วงเวลาของข้อมูล AWR คุณสามารถดู Snapshot ID ที่มีอยู่และช่วงเวลาของมันได้จากมุมมอง `DBA_HIST_SNAPSHOT`
“`sql
SELECT snap_id, begin_interval_time, end_interval_time
FROM dba_hist_snapshot
WHERE dbid = (SELECT dbid FROM v$database) AND instance_number = (SELECT instance_number FROM v$instance)
ORDER BY snap_id DESC;
“`
จากผลลัพธ์ คุณจะเห็นรายการ Snapshot ID พร้อมช่วงเวลาที่เก็บข้อมูล ให้เลือก `begin_snap_id` (เริ่มต้น) และ `end_snap_id` (สิ้นสุด) ที่คุณต้องการวิเคราะห์

2. **รันสคริปต์ awrrpt.sql:** Oracle มีสคริปต์สำเร็จรูปชื่อ `awrrpt.sql` (สำหรับรายงาน AWR ทั่วไป) และ `awrsqrpt.sql` (สำหรับรายงาน AWR ของ SQL Statement เฉพาะ) ที่อยู่ในไดเรกทอรี `$ORACLE_HOME/rdbms/admin/`

ตัวอย่างโค้ด: สร้าง AWR Report ทั่วไป

“`sql
— เข้าสู่ระบบ SQL*Plus ด้วยสิทธิ์ SYSDBA
sqlplus / as sysdba

— รันสคริปต์ awrrpt.sql
@$ORACLE_HOME/rdbms/admin/awrrpt.sql
“`
หลังจากรันสคริปต์ ระบบจะขอข้อมูลเพิ่มเติมดังนี้:

* **Enter the number of days of snapshots to choose from:** (จำนวนวันของ Snapshot ที่จะแสดงให้เลือก)
* ใส่ตัวเลข เช่น `7` เพื่อดู Snapshot ย้อนหลัง 7 วัน

* **Enter the Begin Snapshot Id:** (Snapshot ID เริ่มต้น)
* ใส่ `snap_id` ที่คุณเลือกไว้ เช่น `12345`

* **Enter the End Snapshot Id:** (Snapshot ID สิ้นสุด)
* ใส่ `snap_id` ที่คุณเลือกไว้ เช่น `12346`

* **Enter the Report Type:** (ประเภทรายงาน)
* `html` สำหรับรายงานในรูปแบบ HTML (แนะนำ)
* `text` สำหรับรายงานในรูปแบบ Text
* ใส่ `html`

* **Enter the Report Name:** (ชื่อไฟล์รายงาน)
* ตั้งชื่อไฟล์รายงานของคุณ เช่น `awrrpt_12345_12346.html`

เมื่อป้อนข้อมูลครบถ้วน สคริปต์จะสร้างไฟล์รายงานในไดเรกทอรีที่คุณรัน SQL*Plus หรือในไดเรกทอรีที่ระบุ

ตัวอย่างโค้ด: สร้าง AWR Report สำหรับ SQL Statement เฉพาะ

หากคุณต้องการเจาะจงวิเคราะห์ประสิทธิภาพของ SQL Statement ที่มีปัญหา คุณสามารถใช้ `awrsqrpt.sql`
“`sql
— เข้าสู่ระบบ SQL*Plus ด้วยสิทธิ์ SYSDBA
sqlplus / as sysdba

— รันสคริปต์ awrsqrpt.sql
@$ORACLE_HOME/rdbms/admin/awrsqrpt.sql
“`
สคริปต์จะขอข้อมูลเช่นเดียวกับ `awrrpt.sql` แต่จะมีคำถามเพิ่มเติมดังนี้:

* **Enter the SQL Id:** (SQL ID ที่ต้องการ)
* ใส่ `SQL_ID` ของ SQL Statement ที่คุณต้องการวิเคราะห์ เช่น `g6982x4k2b0t3`

จากนั้นระบบจะสร้างรายงาน HTML หรือ Text ที่เน้นข้อมูลประสิทธิภาพของ SQL Statement นั้นๆ โดยเฉพาะ

ส่วนประกอบสำคัญของ AWR Report ที่ต้องจับตา

AWR Report มีข้อมูลจำนวนมหาศาล การรู้ว่าส่วนใดสำคัญและควรเริ่มต้นที่ใดเป็นสิ่งสำคัญ นี่คือส่วนประกอบหลักที่คุณควรให้ความสนใจ:

1. **Report Summary:** ให้ภาพรวมของฐานข้อมูลและช่วงเวลาที่รายงานครอบคลุม รวมถึง:
* **DB Name, Instance Name, Host Name:** ข้อมูลระบุตัวตนของฐานข้อมูล
* **Snap Id, Begin/End Time, Duration:** ช่วงเวลาที่รายงานครอบคลุม
* **DB Time, DB CPU:** เวลาทั้งหมดที่ฐานข้อมูลใช้ทำงาน (รวมเวลา CPU และ Wait) และเวลา CPU ที่ใช้ไป
* **Load Profile:** สถิติเฉลี่ยต่อวินาที (Per Second) และต่อ Transaction (Per Transaction) ของการทำงานหลักๆ เช่น Redo Size, Logical Reads, Physical Reads, User Calls, Executes, Transactions

2. **Top 5 Timed Foreground Events:** แสดง Wait Events 5 อันดับแรกที่ใช้เวลามากที่สุด Wait Events คือสิ่งที่บอกว่าฐานข้อมูลกำลังรออะไรอยู่ เช่น รอ I/O, รอ Latch, รอการล็อก เป็นต้น นี่คือจุดเริ่มต้นที่ดีในการหาคอขวด

3. **Wait Classes:** จัดกลุ่ม Wait Events เป็นหมวดหมู่ต่างๆ เช่น User I/O, System I/O, Concurrency, Commit, Cluster, Network ซึ่งช่วยให้เข้าใจประเภทของปัญหาได้กว้างขึ้น

4. **SQL ordered by Elapsed Time / CPU / Executions / Gets / Reads:** รายการ SQL Statements ที่ใช้ทรัพยากรมากที่สุด เรียงตามเกณฑ์ต่างๆ ส่วนนี้ช่วยให้เราสามารถระบุ SQL ที่เป็นต้นเหตุของปัญหาประสิทธิภาพได้โดยตรง

5. **IO Stats:** สถิติการทำงาน I/O ของฐานข้อมูล รวมถึง Disk Reads/Writes per Second, Latency ของ Disk I/O

6. **Memory Statistics (SGA/PGA):** ข้อมูลการใช้งานหน่วยความจำของ System Global Area (SGA) และ Program Global Area (PGA) รวมถึง Cache Hit Ratios ต่างๆ

7. **Latch/Mutex Stats:** สถิติเกี่ยวกับ Latch และ Mutex ซึ่งเป็นกลไกการควบคุมการเข้าถึงทรัพยากรที่ใช้ร่วมกัน การมีค่าสูงในส่วนนี้อาจบ่งชี้ถึงปัญหา Concurrency

8. **Segments by Logical Reads / Physical Reads / Writes:** แสดง Object (Table, Index) ที่มีการเข้าถึงข้อมูลมากที่สุด ซึ่งอาจบ่งชี้ถึง Hot Spots ที่ต้องพิจารณาปรับปรุง Index หรือ Partitioning

วิเคราะห์ Performance และหา Bottleneck อย่างมืออาชีพ

การวิเคราะห์ AWR Report ไม่ใช่แค่การอ่านตัวเลข แต่คือการทำความเข้าใจความสัมพันธ์ของตัวเลขเหล่านั้นกับพฤติกรรมของแอปพลิเคชันและโครงสร้างของฐานข้อมูล

เริ่มต้นจาก Report Summary และ Load Profile

* **DB Time vs. DB CPU:**
* ถ้า `DB Time` สูงมาก แต่ `DB CPU` ต่ำ แสดงว่าฐานข้อมูลใช้เวลาส่วนใหญ่ไปกับการรอ (Waiting) ไม่ใช่การประมวลผล ให้ไปดูที่ `Top 5 Timed Foreground Events`
* ถ้า `DB Time` และ `DB CPU` สูงทั้งคู่ แสดงว่าฐานข้อมูลใช้ CPU อย่างหนัก อาจเกิดจาก SQL ที่ไม่มีประสิทธิภาพ หรือ CPU ไม่เพียงพอ

* **Load Profile (Per Second):**
* **Executes per Second:** จำนวน SQL Statement ที่รันต่อวินาที
* **Logical Reads per Second:** จำนวนบล็อกข้อมูลที่อ่านจาก Buffer Cache ต่อวินาที
* **Physical Reads per Second:** จำนวนบล็อกข้อมูลที่อ่านจาก Disk ต่อวินาที
* อัตราส่วน `Logical Reads` ต่อ `Executes` ที่สูงมากอาจบ่งชี้ถึง SQL ที่อ่านข้อมูลมากเกินไป (Inefficient SQL)
* อัตราส่วน `Physical Reads` ต่อ `Logical Reads` ที่สูง อาจบ่งชี้ว่า Buffer Cache ไม่เพียงพอ หรือ I/O เป็นคอขวด

เจาะลึก Top 5 Timed Foreground Events

นี่คือหัวใจของการหาคอขวด หาก `DB Time` ส่วนใหญ่มาจาก Wait Events เหล่านี้คือสิ่งที่คุณต้องแก้ไข
* **`db file sequential read`:** การอ่านบล็อกข้อมูลเดียวจากดิสก์ (มักเกิดจากการใช้ Index) หากสูงมาก อาจบ่งชี้ถึง:
* I/O Subsystem ช้า
* Index ไม่เหมาะสม หรือ Index Scan มากเกินไป
* ข้อมูลกระจัดกระจาย (Fragmentation)
* **`db file scattered read`:** การอ่านหลายบล็อกข้อมูลแบบสุ่มจากดิสก์ (มักเกิดจาก Full Table Scan) หากสูงมาก อาจบ่งชี้ถึง:
* ไม่มี Index ที่เหมาะสม
* Full Table Scan มากเกินไป
* **`log file sync`:** การรอให้ Redo Log เขียนลงดิสก์จนเสร็จสิ้น มักเกิดจาก:
* Commit บ่อยเกินไป (เช่น Commit ใน Loop)
* I/O Subsystem ของ Redo Log ช้า
* **`latch free` / `enq: TX – row lock contention`:**
* **`latch free`:** การรอ Latch ซึ่งเป็นกลไกควบคุมการเข้าถึงโครงสร้างข้อมูลใน SGA มักบ่งชี้ถึงปัญหา Concurrency ในโค้ดแอปพลิเคชัน หรือ Shared Pool Contention
* **`enq: TX – row lock contention`:** การรอ Row Lock ซึ่งเกิดจากการที่ Transaction หนึ่งกำลังล็อกแถวข้อมูลอยู่ และอีก Transaction ต้องการเข้าถึงแถวนั้น บ่งชี้ถึงปัญหา Concurrency ในระดับข้อมูล

ระบุ SQL ที่เป็นปัญหา

ไปที่ส่วน `SQL ordered by Elapsed Time` หรือ `SQL ordered by CPU` เพื่อหา SQL Statement ที่ใช้ทรัพยากรมากที่สุด
* **Elapsed Time:** SQL ที่ใช้เวลารันนานที่สุด
* **CPU Time:** SQL ที่ใช้ CPU มากที่สุด
* **Buffer Gets:** SQL ที่อ่านบล็อกจาก Buffer Cache มากที่สุด
* **Physical Reads:** SQL ที่อ่านบล็อกจาก Disk มากที่สุด
* **Executions:** SQL ที่รันบ่อยที่สุด

จากนั้นให้เลือก `SQL_ID` ของ SQL ที่น่าสงสัย และนำไปวิเคราะห์ต่อด้วย `awrsqrpt.sql` หรือใช้ `EXPLAIN PLAN` เพื่อดู Execution Plan และหาทางปรับปรุง Index, Rewrite Query หรือใช้ Hints

ตรวจสอบ I/O และ Memory Subsystem

* **IO Stats:** ดู `Average Read/Write Time` หากมีค่าสูง (เช่น เกิน 10-20 ms) อาจบ่งชี้ถึงปัญหาที่ Storage หรือ I/O Subsystem
* **Memory Statistics:**
* **Buffer Cache Hit Ratio:** ในอดีตเป็นตัวชี้วัดสำคัญ แต่ปัจจุบันอาจไม่จำเป็นต้อง 99% เสมอไป เพราะบางครั้งการอ่านจาก Disk ก็อาจเร็วกว่าการเก็บใน Cache
* **PGA Memory:** หาก `PGA Aggregate Target` ต่ำกว่า `PGA Allocated` มาก อาจบ่งชี้ว่า PGA Memory ไม่เพียงพอสำหรับ Sorting หรือ Hashing

Latch/Mutex Contention

หาก Wait Events ประเภท `latch free` หรือ `mutex` มีสัดส่วนสูงใน `Top 5 Timed Foreground Events` ให้มาดูรายละเอียดในส่วนนี้ เพื่อระบุประเภทของ Latch หรือ Mutex ที่เกิด Contention การแก้ไขมักเกี่ยวข้องกับการปรับปรุงโค้ดแอปพลิเคชันเพื่อลดการเข้าถึงทรัพยากรที่ใช้ร่วมกัน หรือการปรับจูนพารามิเตอร์ฐานข้อมูลบางตัว

ข้อควรระวังและแนวทางปฏิบัติที่ดีในการใช้ AWR Report

* **ความเข้าใจใน Workload:** AWR Report เป็นเพียงตัวเลข คุณต้องเข้าใจว่าแอปพลิเคชันของคุณทำอะไรอยู่บ้างในช่วงเวลาที่เกิดปัญหา
* **Baseline Performance:** สร้าง AWR Report ในช่วงเวลาที่ระบบมีประสิทธิภาพดี (Baseline) เพื่อใช้เปรียบเทียบเมื่อเกิดปัญหา
* **เปรียบเทียบช่วงเวลา:** เมื่อวิเคราะห์ปัญหา ให้สร้าง AWR Report เปรียบเทียบระหว่างช่วงเวลาที่เกิดปัญหา กับช่วงเวลาที่ระบบทำงานปกติ (AWR Diff Report)
* **Snapshot Interval:** ตรวจสอบให้แน่ใจว่า AWR Snapshot Interval เหมาะสมกับ Workload ของคุณ (ค่าเริ่มต้น 1 ชั่วโมง) บางครั้งอาจต้องลดลงเหลือ 15-30 นาทีในช่วงที่ต้องการเก็บข้อมูลละเอียด
* **อย่าเชื่อตัวเลขเดียว:** อย่าเพิ่งสรุปจากตัวเลขเดียว ให้พิจารณาหลายๆ เมตริกและดูความสัมพันธ์กัน
* **Licensing:** ตระหนักถึงข้อกำหนดด้านไลเซนส์ของ Oracle Diagnostic Pack

เมตริกใน AWR Report	บ่งชี้ถึง Bottleneck ที่อาจเกิดจาก	แนวทางแก้ไขเบื้องต้น
DB Time สูง, DB CPU ต่ำ	Waiting (I/O, Lock, Commit)	วิเคราะห์ Top 5 Timed Events, ตรวจสอบ I/O Subsystem, Lock Contention
DB Time สูง, DB CPU สูง	CPU Contention, Inefficient SQL	ระบุ SQL ที่ใช้ CPU สูงสุด, Optimize SQL, เพิ่ม CPU Resource
Top 5 Events: db file sequential read	I/O Subsystem ช้า, Index ไม่เหมาะสม	ตรวจสอบ Storage Performance, ตรวจสอบ Index, Partitioning
Top 5 Events: log file sync	Commit บ่อย, Redo Log I/O ช้า	Batch Commits, ย้าย Redo Log ไปยัง Storage ที่เร็วขึ้น
Top 5 Events: enq: TX – row lock contention	Concurrency, Row Locking	ตรวจสอบ Transaction ที่ยาวนาน, Optimize Application Code เพื่อลด Lock
SQL ordered by Elapsed Time สูง	Inefficient SQL Query	วิเคราะห์ Execution Plan, เพิ่ม/ปรับปรุง Index, Rewrite Query
Physical Reads per Second สูง	Buffer Cache ไม่เพียงพอ, Full Table Scan	เพิ่ม SGA Size, Optimize SQL เพื่อลด Physical Reads
Latch Free / Mutex Wait สูง	Concurrency, Shared Pool Contention	ตรวจสอบ Application Code, ปรับแต่งพารามิเตอร์ Shared Pool

สรุปภาพรวมและข้อเสนอแนะ

AWR Report เป็นเครื่องมืออันล้ำค่าและขาดไม่ได้สำหรับ DBA ทุกคนในการวิเคราะห์และปรับแต่งประสิทธิภาพของฐานข้อมูล Oracle การทำความเข้าใจส่วนประกอบต่างๆ ของรายงาน การตีความเมตริกอย่างถูกต้อง และการเชื่อมโยงข้อมูลเหล่านั้นเข้ากับพฤติกรรมของแอปพลิเคชัน คือกุญแจสำคัญสู่การเป็นมืออาชีพในการแก้ปัญหา Performance

เริ่มต้นด้วยการทำความคุ้นเคยกับ AWR Report ในสภาพแวดล้อมที่ทำงานปกติของคุณ สร้าง Baseline Reports และเมื่อใดก็ตามที่เกิดปัญหา อย่าลังเลที่จะสร้าง AWR Report ในทันทีเพื่อจับภาพสถานะของระบบ การวิเคราะห์อย่างเป็นระบบ เริ่มต้นจากภาพรวม (Report Summary, Top 5 Events) แล้วค่อยๆ เจาะลึกไปยังรายละเอียด (SQL Stats, I/O Stats, Latch Stats) จะช่วยให้คุณระบุและแก้ไขปัญหาได้อย่างมีประสิทธิภาพ

ในฐานะนักเขียนบทความเทคโนโลยีที่มีประสบการณ์กว่าสิบปี ผมขอยืนยันว่า AWR Report คือหนึ่งในทักษะที่สำคัญที่สุดที่ DBA ควรมี เพื่อให้มั่นใจว่าฐานข้อมูลของคุณจะทำงานได้อย่างราบรื่นและรองรับความต้องการของธุรกิจได้อย่างต่อเนื่อง การเรียนรู้และฝึกฝนการใช้งาน AWR Report อย่างสม่ำเสมอ จะช่วยยกระดับความสามารถของคุณในการจัดการฐานข้อมูล Oracle ไปอีกขั้นอย่างแน่นอน