อย่ามาเสียใจภายหลัง หากไม่ได้เปิด ARCHIVELOG mode

บ่ายวันศุกร์ developer จะ drop user test เพื่อเตรียมโหลดข้อมูลจาก product เข้ามาใหม่ แต่ดันดูผิด ไปลบ user จริงบน production

developer วิ่งหน้าตื่นเข้ามาถาม DBA

"กู้กลับไปเมื่อชั่วโมงที่แล้วได้ไหม"

DBA เปิดเครื่องมือขึ้นมาดูแล้วหัวใจร่วงไปอยู่ที่ตาตุ่ม เพราะระบบรันอยู่ในโหมดที่เรียกว่า NOARCHIVELOG สิ่งที่ต้องบอกทีมคือกู้ได้แค่ backup ได้ข้อมูลแค่เมื่อคืน ส่วนงานวันนี้ทั้งวันหายหมด ไม่ใช่เพราะฝีมือไม่ถึงนะครับ แต่เพราะทางเลือกนั้นถูกปิดตายไปตั้งแต่วันติดตั้งระบบแล้ว

ทบทวนเรื่อง redo log กันก่อน

Oracle บันทึกทุกการเปลี่ยนแปลงลงไฟล์ที่ชื่อ redo log อยู่แล้ว ใครแก้อะไร ตอนไหน จดหมด

แต่ redo log มีจำนวนจำกัด สมมติมีสามไฟล์ พอเขียนเต็มไฟล์แรกก็ย้ายไปไฟล์ที่สอง เต็มอีกก็ไปไฟล์ที่สาม แล้วพอเต็มหมดจะทำยังไง

คำตอบคือมันวนกลับมาเขียนทับไฟล์แรก ดังนั้นการเปลี่ยนแปลงในช่วงแรกถูกเขียนทับไปแล้ว ไม่สามารถกู้คืนย้อนได้ไกล

ARCHIVEDLOG Mode ทั้งสองแบบต่างกันอย่างไร

NOARCHIVELOG วนทับการเปลี่ยนแปลงเลย ประวัติการเปลี่ยนแปลงเก่าหายไปตลอดเวลา ผลคือเรากู้ข้อมูลได้แค่จุดที่ backup ไว้ล่าสุดเท่านั้น จะย้อนไปเวลาที่ต้องการไม่ได้

ARCHIVELOG ก่อนวนทับ Oracle จะคัดลอกการเปลี่ยนแปลงออกมาเก็บไว้ก่อน เรียกว่า archived log พอมีสำเนาการเปลี่ยนแปลงครบทุกช่วงเวลา เราจึงย้อนกลับไปจุดไหนก็ได้ ความสามารถนี้เรียกว่า point-in-time recovery และมันยังเป็นเงื่อนไขจำเป็นของการ backup ขณะระบบยังเปิดใช้งานอยู่ด้วย

เทียบง่าย ๆ ARCHIVELOG ก็เหมือนกล้องวงจรปิด วันที่ไม่มีเรื่องอะไรมันดูเปลืองพื้นที่เก็บ แต่วันที่เกิดเรื่องขึ้นมาจริง มันคือของชิ้นเดียวที่พาเราย้อนเวลากลับไปดูได้

เช็คว่าเราเปิด ARCHIVELOG Mode อยู่หรือเปล่า

SELECT log_mode FROM v$database;

-- LOG_MODE
-- NOARCHIVELOG

ถ้าเห็นแบบนี้บนระบบงานจริง ควรวางแผนเปิดโดยเร็วครับ ระบบ production ควรเป็น ARCHIVELOG แทบทุกกรณี ส่วน NOARCHIVELOG เหมาะกับเครื่องที่ใช้ทดลองหรือฝึกเขียนโค้ด ข้อมูลหายก็สร้างใหม่ได้ไม่เจ็บตัว

ลองสั่ง backup ทั้งระบบขณะเปิดใช้งานอยู่ดู จะเจอของจริงทันที

RMAN> BACKUP DATABASE;

RMAN-03009: failure of backup command
ORA-19602: cannot backup or copy active file in NOARCHIVELOG mode

หากเป็น NOARCHIVEDLOG Mode จะไม่สามารถ backup ฐานข้อมูลที่กำลังเปิดรันอยู่ได้ ต้องปิดฐานข้อมูลก่อน ซึ่งระบบที่ต้องเปิดตลอดเวลา จะให้ปิดฐานข้อมูลเพื่อ backup ก็คงไม่ได้

วิธีเปิด ARCHIVEDLOG Mode ใช้เวลาไม่ถึงห้านาที

ใช้เวลาไม่นาน แต่ต้องมีช่วงหยุดระบบสั้น ๆ (down time) พราะต้องกลับไปที่สถานะ MOUNT ก่อน

SHUTDOWN IMMEDIATE;
STARTUP MOUNT;
ALTER DATABASE ARCHIVELOG;
ALTER DATABASE OPEN;

SELECT log_mode FROM v$database;
-- LOG_MODE
-- ARCHIVELOG

เท่านี้ Oracle จะเริ่มเก็บ archived log ให้อัตโนมัติ

เปิดแล้วยังไม่จบ มีงานต้องคิดอีก 3 เรื่อง

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

ตั้งรอบลบให้ถูกวิธี ใช้เครื่องมือของ Oracle จัดการลบไฟล์ที่ backup ไปแล้ว ห้ามไปลบไฟล์เองด้วยมือเด็ดขาด เพราะระบบจะยังคิดว่าไฟล์นั้นมีอยู่

ซ้อมกู้จริง ข้อนี้คนข้ามกันเยอะที่สุด มี archived log ครบแต่ไม่เคยลองกู้เลย ก็ยังเสี่ยงอยู่ดี หาโอกาสซ้อมบนเครื่องทดสอบอย่างน้อยปีละครั้ง

สองคำถามที่ตามมาเสมอ

"เปิดแล้วระบบช้าลงไหม" แทบไม่รู้สึกครับ งานคัดลอก redo เป็นหน้าที่ของโปรเซสเบื้องหลังที่ทำงานแยกจากงานของผู้ใช้ ระบบทั่วไปมองไม่เห็นความต่าง ยกเว้นระบบที่เขียนข้อมูลหนักมากจริง ๆ ซึ่งก็แก้ได้ด้วยการวางไฟล์ไว้บนดิสก์ที่เร็วพอ เทียบกับความเสี่ยงที่ปิดโหมดนี้ไว้ ผมว่าคุ้มเกินคุ้ม

"ต้องจ่ายเพิ่มไหม" ไม่ต้องครับ ARCHIVELOG เป็นความสามารถมาตรฐานของ Oracle ทุกรุ่น ไม่เหมือนของบางอย่างที่ต้องซื้อ option เพิ่ม เพราะฉะนั้นเหตุผลเดียวที่ระบบ production ยังเป็น NOARCHIVELOG อยู่ มักไม่ใช่เรื่องเงิน แต่เป็นเพราะไม่มีใครกลับไปเช็คหลังติดตั้งเสร็จ

สรุป

ความสามารถในการกู้ข้อมูลของเรา ถูกกำหนดไว้ตั้งแต่วันติดตั้งระบบ ไม่ใช่วันที่เกิดเหตุ NOARCHIVELOG แปลว่ากู้ได้แค่จุดที่ backup ล่าสุด ส่วน ARCHIVELOG ทำให้ย้อนไปเวลาที่ต้องการได้ เปิดใช้แค่สี่คำสั่ง แต่ต้องดูแลพื้นที่ ตั้งรอบลบให้ถูก และซ้อมกู้บ้าง

ไปเช็คระบบที่ดูแลอยู่ตอนนี้เลยครับ คำสั่งเดียวก็รู้แล้ว

ผมเขียนเรื่อง Oracle และ SQL แบบนี้ทุกสัปดาห์ ทั้งทิปสั้นและเคสที่เจอกันบ่อยในวงการ ติดตามได้ที่เพจ Facebook อาจารย์ตี๋ที่สอน Oracle ครับ