SYSAUX เต็มจน Oracle ประมวลผลต่อไม่ได้ | Audit Trail และการเติบโตของ Tablespace

เรื่องราวของเหตุการณ์ · Case Story

Application ค้างโดยไม่มีสัญญาณเตือนล่วงหน้า

เหตุการณ์เริ่มเมื่อผู้ใช้พบว่า Application ไม่ตอบสนองและทีม IT ตรวจพบ Error จาก Oracle ที่เกี่ยวข้องกับพื้นที่ไม่เพียงพอ สิ่งที่ทำให้สถานการณ์ดูขัดแย้งคือทีมตรวจสอบพื้นที่ Disk ของเครื่องแล้วพบว่ายังว่าง และ Tablespace ที่ใช้เก็บข้อมูลระบบงานก็ยังไม่เต็ม

ทีมจึงเปลี่ยนทิศทางไปตรวจ SYSAUX (Tablespace ภายในที่ Oracle จัดเตรียมไว้สำหรับ Component ของตัวเอง เช่น AWR, Scheduler และ Audit Trail) และพบว่าพื้นที่ใน SYSAUX หมดแล้ว

ข้อมูลระบบงาน → Tablespace ของ Application → Disk

แต่ Oracle ยังมี Tablespace ภายใน อย่าง SYSTEM และ SYSAUX ที่ Oracle ใช้เอง

Audit Trail, AWR, Scheduler → SYSAUX → Disk

เมื่อ SYSAUX เต็ม Component ต่าง ๆ ที่อาศัย Tablespace นี้อาจหยุดทำงานพร้อมกัน

เข้าใจ 3 คำนี้ก็เห็นภาพทั้งหมด

SYSAUX — ห้องเครื่องของ Oracle: เป็น Tablespace ที่ Oracle สร้างและดูแลเอง เก็บข้อมูลการทำงานภายในหลายอย่าง เช่น สถิติประสิทธิภาพ (AWR), ประวัติงานที่ Oracle รัน (Scheduler) และบันทึกกิจกรรมของผู้ใช้ (Audit Trail) ผู้ดูแลระบบมักไม่ได้เฝ้าดูขนาดของ SYSAUX เพราะไม่ได้ใช้เก็บข้อมูลระบบงานโดยตรง
Audit Trail — สมุดบันทึกกิจกรรม: เมื่อเปิดใช้ Oracle Audit Oracle จะบันทึกว่าใครเข้าสู่ระบบ ทำคำสั่งอะไร และเมื่อไร บันทึกเหล่านี้เขียนลงใน SYS.AUD$ หรือ Unified Audit Trail ซึ่งอยู่ใน SYSAUX ถ้าไม่มีการล้างออกเป็นระยะ ขนาดจะโตขึ้นเรื่อย ๆ
Occupant — ผู้ใช้พื้นที่ใน SYSAUX: Oracle มีชื่อเรียกสำหรับแต่ละ Component ที่ใช้พื้นที่ใน SYSAUX ว่า "Occupant" ดูได้จาก V$SYSAUX_OCCUPANTS ซึ่งจะบอกว่า Component ใดใช้พื้นที่เท่าไร

เส้นทางการวิเคราะห์ · The Investigation

ทำไม SYSAUX จึงโตโดยไม่มีใครสังเกต

บทที่ 1 · หาว่าใครใช้พื้นที่

V$SYSAUX_OCCUPANTS ชี้ให้เห็นว่า Audit Trail เป็นผู้ใช้พื้นที่หลัก

ทีมตรวจ V$SYSAUX_OCCUPANTS (ตารางระบบที่แสดงรายชื่อและขนาดของแต่ละ Component ที่อยู่ใน SYSAUX) และพบว่าพื้นที่ส่วนใหญ่อยู่ที่ Audit Trail Component ขณะที่ Component อื่น เช่น AWR และ Scheduler ใช้พื้นที่ในระดับที่คาดได้

นอกจากนั้นทีมยังตรวจ Segment ของ SYS.AUD$ เพื่อดูขนาดจริงและแนวโน้มการเติบโต ซึ่งยืนยันว่า Audit Trail สะสมมาเป็นเวลานานโดยไม่มี Housekeeping หรือ Retention Policy ที่กำหนดไว้

บทที่ 2 · ทำไมไม่มีใครรู้ล่วงหน้า

SYSAUX ไม่ได้ถูก Monitor เหมือน Tablespace ของระบบงาน

ทีมงานส่วนใหญ่ตั้ง Alert สำหรับ Tablespace ที่เก็บข้อมูลระบบงาน แต่ SYSAUX มักไม่ถูกรวมอยู่ใน Monitoring เพราะไม่ได้เป็น Tablespace ที่ผู้ดูแลระบบสร้างหรือดูแลเองโดยตรง

ขณะเดียวกัน Audit Trail ก็เติบโตอย่างสม่ำเสมอตามจำนวนการเข้าใช้งานระบบทุกวัน แต่เนื่องจากไม่มี Retention Policy กำหนดว่าบันทึกเก่าเกินกี่วันให้ตัดออก ข้อมูลจึงสะสมและโตขึ้นโดยไม่มีจุดหยุด

บทที่ 3 · ตรวจ Audit Configuration ก่อนแก้

ต้องรู้ว่าใช้ Traditional หรือ Unified Audit ก่อนเลือกวิธี Housekeeping

Oracle รองรับ Audit ได้หลายรูปแบบและแต่ละรูปแบบเก็บข้อมูลต่างกัน ทีมตรวจว่าระบบใช้ Traditional Audit (เก็บใน SYS.AUD$ ใน SYSAUX) หรือ Unified Audit (เก็บใน AUDSYS Schema) เพราะวิธี Purge และ Package ที่ใช้จัดการต่างกัน

ทีมยังตรวจด้วยว่า Audit Policy ที่เปิดอยู่บันทึกกิจกรรมอะไรบ้าง เพราะถ้า Audit ครอบคลุมเกินความจำเป็น ข้อมูลก็จะโตเร็วกว่าที่ควร และการลด Audit Scope อาจช่วยชะลอการเติบโตได้โดยไม่กระทบ Compliance

จุดที่ทีมพบ: Audit Trail สะสมมาเป็นเวลานาน, ไม่มี Retention Policy กำหนดไว้, และ SYSAUX ไม่ได้ถูกรวมอยู่ใน Monitoring ของทีม ทำให้ไม่มีสัญญาณเตือนก่อนพื้นที่เต็ม

เบื้องหลังการแก้ · What We Did

แก้สองระดับพร้อมกัน: กู้บริการก่อน แล้วจัดการสาเหตุ

ทีมไม่ได้รอให้วิเคราะห์สาเหตุเสร็จสมบูรณ์ก่อนจึงค่อยเริ่มกู้บริการ แต่แยกงานออกเป็นสองส่วนที่ดำเนินการต่อเนื่องกัน

⚡ ระดับที่ 1 — กู้บริการฉุกเฉิน

ตรวจ Datafile ของ SYSAUX และขนาดที่เหลือ
ยืนยันว่า Disk มีพื้นที่พอสำหรับขยาย
เพิ่ม Datafile ใหม่ให้ SYSAUX เพื่อให้ Oracle Component กลับมาเขียนข้อมูลได้
ทดสอบว่า Application กลับมาตอบสนองได้ตามปกติ

🔧 ระดับที่ 2 — ควบคุมการเติบโตระยะยาว

ตรวจ Audit Configuration และยืนยัน Audit Mode ที่ใช้งาน
ทบทวน Retention Policy ร่วมกับเจ้าของระบบตาม Compliance ที่องค์กรกำหนด
ใช้ DBMS_AUDIT_MGMT กำหนด Purge Job พร้อม Archive ข้อมูลก่อนล้าง
เพิ่ม SYSAUX เข้าไปใน Monitoring เพื่อแจ้งเตือนก่อนพื้นที่กระทบระบบอีกครั้ง

สิ่งที่ทีมไม่ทำทันที: ไม่ปิด Audit และไม่ TRUNCATE SYS.AUD$ โดยตรง เพราะ Audit Trail ที่ยังไม่ได้ Archive อาจต้องใช้ในการตรวจสอบย้อนหลังตาม Compliance ทีมจึงทำ Archive ก่อนทุกครั้ง และดำเนินการตาม Package และ Procedure ที่ Oracle รองรับอย่างเป็นทางการ

ผลหลังดำเนินการ: Oracle กลับมาประมวลผลได้ ผู้ใช้เข้าใช้งาน Application ได้ตามปกติ และทีมมีกรอบ Housekeeping พร้อม Monitoring ที่จะแจ้งเตือนก่อนที่ SYSAUX จะกระทบระบบอีกครั้ง

ห้องเทคนิค · For DBA/IT

เปิดดู SYSAUX, Audit Modes และจุดตรวจสำหรับ DBA

รายละเอียดด้านล่างเก็บศัพท์และบริบท Oracle ไว้ครบสำหรับ DBA/IT และการค้นหา แต่พับไว้เพื่อไม่ให้ขัดจังหวะเรื่องราวหลัก

SYSAUX Tablespace คืออะไร และมี Component อะไรอยู่บ้าง

SYSAUX ถูกสร้างโดยอัตโนมัติพร้อมกับ Oracle Database เพื่อแบ่งเบาภาระของ SYSTEM Tablespace Component ที่อาศัยอยู่ใน SYSAUX เรียกว่า Occupant ดูได้ผ่าน V$SYSAUX_OCCUPANTS

Occupant Name	สิ่งที่เก็บ	ความเสี่ยงที่มักพบ
`SM/AWR`	AWR Snapshots, Baselines	โตถ้า Retention ยาวหรือ Snapshot บ่อย
`AUDSYS`	Unified Audit Trail (Oracle 12c+)	โตตามปริมาณ Audit Activity
`SYS.AUD$`	Traditional Audit Trail	โตถ้าไม่มี Purge Policy
`SM/OPTSTAT`	Object Statistics History	โตถ้า Retention ยาว

ก่อนตัดสินใจแก้ควรระบุ Occupant จริงที่ใช้พื้นที่มากก่อนเสมอ ไม่ควรสรุปจากชื่อ Tablespace หรือ Error เพียงอย่างเดียว

Oracle Audit Trail ต่างกันอย่างไร และเก็บข้อมูลไว้ที่ใด

Oracle รองรับ Audit ได้หลายรูปแบบ และแต่ละรูปแบบเก็บข้อมูลในที่ต่างกัน:

Audit Mode	ที่เก็บข้อมูล	Oracle Version
Traditional Database Audit	`SYS.AUD$` ใน SYSAUX (ค่าเริ่มต้น) หรือ OS File	ทุก Version
Unified Auditing	`AUDSYS.AUD$UNIFIED` ใน SYSAUX	12c ขึ้นไป
Mixed Mode	ทั้งสองแบบข้างต้นพร้อมกัน	12c ในช่วง Migration

การระบุ Audit Mode ที่ใช้งานจริงเป็นขั้นตอนแรกก่อน Housekeeping เสมอ เพราะ Package และ Procedure ที่ใช้จัดการต่างกันในแต่ละ Mode

DBMS_AUDIT_MGMT ใช้ทำอะไร และควรระวังอะไรก่อนใช้

DBMS_AUDIT_MGMT เป็น Package ที่ Oracle รองรับอย่างเป็นทางการสำหรับจัดการ Audit Trail ทั้ง Traditional และ Unified ฟังก์ชันหลักที่ทีมใช้:

INIT_CLEANUP — เตรียม Audit Trail สำหรับ Housekeeping และกำหนด Default Cleanup Interval
SET_LAST_ARCHIVE_TIMESTAMP — กำหนดว่าข้อมูลก่อนเวลานี้ Archive แล้วและพร้อม Purge
CREATE_PURGE_JOB — สร้าง Job ที่รันตามกำหนดเวลาเพื่อล้างข้อมูลที่ Archive แล้ว

ข้อควรระวังก่อนใช้:

ยืนยัน Audit Mode ที่ใช้งานจริงก่อน เพราะ Procedure บางตัวใช้ได้เฉพาะบาง Mode
Archive ข้อมูลก่อน Purge ทุกครั้ง โดยตรวจสอบกับเจ้าของระบบว่าข้อมูลชุดใดต้องเก็บตาม Compliance
ทดสอบในสภาพแวดล้อมที่ไม่ใช่ Production ก่อน และมีแผน Rollback ไว้
วัดผลด้วย AWR หรือ SQL Statistics หลังการเปลี่ยนแปลง ไม่ใช่ดูแค่ขนาด Tablespace

จะ Monitor SYSAUX อย่างไรไม่ให้พลาดสัญญาณก่อนเต็ม

หลังแก้ปัญหานี้ ทีมเพิ่ม SYSAUX เข้าไปใน Monitoring ด้วยชุดคำถามพื้นฐาน:

ขนาดของ SYSAUX และ Free Space เปลี่ยนแปลงอย่างไรเทียบกับ Baseline ของสัปดาห์ที่แล้ว
Occupant ใดใช้พื้นที่มากที่สุดและโตเร็วแค่ไหนต่อสัปดาห์
ขนาดปัจจุบันของ Audit Trail เทียบกับ Threshold ที่กำหนดไว้
Purge Job รันสำเร็จในรอบที่กำหนดหรือไม่

Oracle Tablespace Alert Threshold ใน Database Control หรือ Cloud Control ก็ช่วยได้ แต่ต้องเพิ่ม SYSAUX ไว้ในรายการนั้นด้วย เพราะบางระบบตั้งค่าเฉพาะ Tablespace ของระบบงานไว้เท่านั้น

แหล่งข้อมูล · Sources

ที่มาของคำอธิบาย SYSAUX และ Oracle Audit Management

บริบทของ Case: บันทึกการแก้ปัญหาจากงานภาคสนาม โดยไม่เผยแพร่ชื่อองค์กร, Hostname, Schema, Object หรือรายละเอียดที่ระบุตัวระบบได้
SYSAUX Occupants: Oracle Reference: V$SYSAUX_OCCUPANTS
DBMS_AUDIT_MGMT: Oracle PL/SQL Packages and Types Reference: DBMS_AUDIT_MGMT
Unified Auditing: Oracle Database Security Guide: Introduction to Auditing
Managing SYSAUX: Oracle Database Administrator's Guide: Managing the SYSAUX Tablespace

SYSAUX โตเร็วผิดปกติ หรือระบบเคยหยุดเพราะ Oracle Component ทำงานไม่ได้?

ทีม VT Technology ช่วยตรวจ Occupant ที่ใช้พื้นที่ใน SYSAUX, วาง Retention Policy และกำหนด Purge Job ที่เหมาะกับ Oracle Version และ Compliance ขององค์กร พร้อมเพิ่ม Monitoring ก่อนพื้นที่กระทบผู้ใช้อีกครั้ง

ปรึกษาปัญหา Oracle Capacity และ Audit

Oracle หยุดประมวลผลเพราะ SYSAUX เต็ม — ทั้งที่ไม่มีใครคาดมาก่อน