การจัดการการสำรองข้อมูลฐานข้อมูล Oracle เป็นความท้าทายประจำวันของผู้ดูแลระบบแต่ละคน คุณต้องชั่งน้ำหนักต้นทุนการจัดเก็บข้อมูลกับความต้องการในการกู้คืน พร้อมทั้งรับประกันว่าสอดคล้องตามข้อกำหนดทางธุรกิจ จะตัดสินใจอย่างไรว่าควรเก็บการสำรองข้อมูลใดไว้ และการสำรองข้อมูลใดปลอดภัยที่จะลบได้? นี่คือจุดที่ นโยบายการเก็บรักษา RMAN มีความสำคัญยิ่ง โดยการกำหนดค่าอย่างระมัดระวัง คุณสามารถทำให้กระบวนการล้างข้อมูลสำรองอัตโนมัติ ประหยัดพื้นที่ดิสก์ และรับประกันว่าจุดกู้คืนที่สำคัญจะสามารถใช้งานได้เสมอเมื่อเกิดภัยพิบัติ เรามาเรียนรู้กันว่านโยบายการเก็บรักษา RMAN ทำงานอย่างไรในทุกระดับ ตั้งแต่พื้นฐานไปจนถึงการดำเนินการอัตโนมัติขั้นสูง เพื่อให้คุณสามารถตัดสินใจอย่างรอบรู้สำหรับสภาพแวดล้อมของคุณ
RMAN Retention Policy คืออะไร?
นโยบาย RMAN retention policy กำหนดกฎเกณฑ์ที่บอก Oracle Recovery Manager (RMAN) ว่าควรเก็บข้อมูลสำรองไว้นานแค่ไหน และควรเก็บสำเนากี่ชุดบนดิสก์หรือเทป โดยการตั้งนโยบายนี้ คุณจะให้คำแนะนำที่ชัดเจนกับ RMAN เกี่ยวกับข้อมูลสำรองใดที่ยังต้องใช้ในการกู้คืน และข้อมูลใดที่กลายเป็นข้อมูลล้าสมัยแล้ว
เมื่อ RMAN ระบุว่าการสำรองข้อมูลถูกทิ้งใช้งานแล้ว หมายความว่าการสำรองข้อมูลนั้นไม่จำเป็นต่อเป้าหมายการกู้คืนข้อมูลที่คุณกำหนดไว้อีกต่อไป ไฟล์ที่ถูกทิ้งใช้งานเหล่านี้สามารถลบออกได้อย่างปลอดภัย โดยไม่กระทบต่อความสามารถในการกู้คืนข้อมูลภายในช่วงเวลาหรือระดับซ้ำซ้อนที่คุณเลือกไว้
คุณตั้งค่านโยบายการเก็บรักษาโดยใช้คำสั่ง CONFIGURE RETENTION POLICY ภายใน RMAN นโยบายนี้จะถูกนำไปใช้โดยตรงกับการสำรองข้อมูลไฟล์ข้อมูลแบบเต็ม (ระดับ 0) และการสำรองไฟล์ควบคุม แต่ยังส่งผลต่อการสำรองข้อมูลเพิ่มเติมและการบันทึก redo ที่ถูกจัดเก็บไว้โดยอ้อม เนื่องจากไฟล์เหล่านั้นอาจจำเป็นต่อการกู้คืนจากรายการสำรองไฟล์ข้อมูลที่ถูกเก็บไว้
สิ่งสำคัญที่ต้องทราบคือ RMAN จะไม่ลบไฟล์ที่ล้าสมัยโดยอัตโนมัติหลังจากทำเครื่องหมายแล้ว คุณต้องรันคำสั่ง DELETE OBSOLETE ด้วยตนเองหรือตั้งเวลาให้ดำเนินการเป็นส่วนหนึ่งของการบำรุงรักษาตามปกติ
ทำไมควรใช้นโยบายการเก็บรักษา RMAN
นโยบายการเก็บรักษาที่ชัดเจนไม่เพียงจัดการไฟล์เก่าให้เป็นระเบียบเท่านั้น แต่ยังเป็นพื้นฐานสำคัญของการบริหารจัดการสำรองข้อมูลอย่างมีวินัยในสภาพแวดล้อม Oracle ที่จริงจังทุกแห่ง หากไม่มีนโยบายนี้ สำเนาข้อมูลสำรองที่ล้าสมัยจะสะสมอย่างไม่สามารถควบคุมได้ ส่งผลให้สิ้นเปลืองพื้นที่จัดเก็บอันมีค่า และเพิ่มภาระงานด้านการบริหารเมื่อมีการตรวจสอบหรือกู้คืนข้อมูล
ด้วยนโยบายที่เหมาะสม:
จุดกู้คืนที่จำเป็นจะไม่สูญหายโดยไม่ได้ตั้งใจเนื่องจากการลบด้วยตนเอง
การทำความสะอาดจะกลายเป็นกระบวนการทำงานโดยอัตโนมัติ แทนที่การคาดเดาซึ่งอาจเกิดข้อผิดพลาด
การปฏิบัติตาม มาตรฐานการกำกับดูแลองค์กร เช่น การตอบสนองต่อ RPO (เป้าหมายการกู้คืนจุดข้อมูล) หรือ RTO (เป้าหมายเวลาการกู้คืน) จะทำได้ง่ายขึ้น เนื่องจากนโยบายจะกำหนดการคุ้มครองขั้นต่ำไว้
ข้อผิดพลาดแบบทำด้วยมือลดลงเนื่องจากสคริปต์จัดการงานตามปกติแทนที่มนุษย์ซึ่งต้องคัดกรองไฟล์หลายร้อยไฟล์ด้วยตนเอง
ลองคิดดูสิ: คุณจะให้เวลาหลายชั่วโมงไปกับการเรียงลำดับชุดข้อมูลสำรองเก่า หรือให้ RMAN จัดการทุกอย่างตามกฎที่ชัดเจนแทนล่ะ?
ประเภทของนโยบายการเก็บรักษารูปแบบ RMAN
Oracle มีสองประเภทหลักของนโยบายการเก็บรักษารูปแบบ RMAN ได้แก่ ช่วงเวลาการกู้คืน (Recovery Window) และ ความซ้ำซ้อน (Redundancy) แต่ละประเภทตอบสนองความต้องการในการดำเนินงานที่แตกต่างกัน ขึ้นอยู่กับวิธีที่คุณกำหนดว่า "เพียงพอ" สำหรับการปกป้องข้อมูลของคุณ
สิ่งแรกคือ หน้าต่างกู้คืน ซึ่งจะเก็บสำเนาข้อมูลสำรองทั้งหมดที่จำเป็นไว้ เพื่อให้คุณสามารถกู้คืนฐานข้อมูลกลับไปยังจุดใดจุดหนึ่งภายในช่วงจำนวนวันที่กำหนด ตัวอย่างเช่น เมื่อเจ็ดวันก่อน หากตั้งค่าไว้ตามนั้น แนวทางนี้รับประกันการกู้คืนข้อมูล ณ จุดเวลาใดๆ ภายในช่วงเวลานั้น โดยไม่ขึ้นกับว่าจะมีไฟล์สำรองจริงกี่ฉบับในระหว่างวันเหล่านั้น
ถัดไปคือ Redundancy ซึ่งเน้นเพียงการเก็บสำเนาข้อมูลสำรองล่าสุดจำนวนคงที่ต่อไฟล์ข้อมูลหรือไฟล์ควบคุม เช่น เก็บสองหรือสามเวอร์ชันล่าสุดเท่านั้น และจะทำเครื่องหมายข้อมูลที่เก่ากว่านั้นว่าล้าสมัยทันทีที่มีเวอร์ชันใหม่ปรากฏขึ้น
คุณไม่สามารถใช้ทั้งสองอย่างพร้อมกันได้ ต่อหนึ่งอินสแตนซ์ฐานข้อมูลจะมีเพียงประเภทเดียวเท่านั้นที่สามารถทำงานได้ในเวลาใดเวลาหนึ่ง หากไม่มีการเลือกโดยชัดเจนหลังจากเริ่มการติดตั้ง/การกำหนดค่า Oracle จะใช้ค่าเริ่มต้นแบบเงียบ ๆ เป็น REDUNDANCY 1 ซึ่งหมายความว่าจะพิจารณาจำเป็นต้องมีเพียงสำเนาเดียวต่อไฟล์ เว้นแต่ผู้ดูแลระบบจะเปลี่ยนแปลงในภายหลัง
การเลือกระหว่าง Recovery Window และ Redundancy
คุณจะเลือกกลยุทธ์ไหนระหว่างทั้งสองกลยุทธ์ ก็ขึ้นอยู่กับความต้องการทางธุรกิจเป็นหลัก
หากข้อกำหนดระบุว่า "เราต้องสามารถกู้คืนระบบของเราให้ย้อนกลับไปได้จนถึง X วันก่อนหน้า" แล้ว ให้เลือก ช่วงการกู้คืน (RECOVERY WINDOW) ซึ่งจะรับประกันการครอบคลุมอย่างต่อเนื่องตามระยะเวลา โดยไม่ขึ้นกับความถี่ของการสำรองข้อมูลแต่ละครั้งหรือการเปลี่ยนแปลงของขนาดข้อมูลรายวัน
หากความกังวลของคุณเกี่ยวกับความทนทานของฮาร์ดแวร์ ("เราต้องการสำเนาที่ดีสามชุดแยกจากกัน เพื่อป้องกันเหตุไม่คาดฝัน") ให้เลือก การซ้ำซ้อน (REDUNDANCY) วิธีนี้จะทำให้สิ่งต่าง ๆ เรียบง่าย แต่ไม่สามารถรับประกันการสำรองข้อมูล ณ จุดเวลาใดจุดเวลาหนึ่งได้ เว้นแต่ว่าจะมีการรันไฟล์เต็มหรือเพิ่มเติมอย่างสมบูรณ์ในรอบ N ครั้งล่าสุด
สำหรับสภาพแวดล้อมการผลิตส่วนใหญ่ที่ต้องการความสามารถในการกู้คืนข้อมูล ณ เวลาที่กำหนดอย่างแม่นยำ ซึ่งเป็นความต้องการทั่วไปในปัจจุบัน วิธีหน้าต่างการกู้คืนยังคงถือเป็นแนวทางปฏิบัติมาตรฐานที่ดีที่สุด
การกำหนดค่ารูปแบบการเก็บรักษา RMAN ทำอย่างไร?
การกำหนดกลยุทธ์การเก็บรักษาอย่างมีประสิทธิภาพต้องอาศัยความเข้าใจทั้งทางด้านรูปแบบคำสั่งและการมีนัยสำคัญของแต่ละคำสั่งที่ใช้ภายในเซสชัน RMAN สิ่งเหล่านี้คือสิ่งที่ผู้ดูแลระบบปฏิบัติการควรรู้ก่อนทำการเปลี่ยนแปลง:
เริ่มต้นด้วยการเชื่อมต่ออย่างปลอดภัยผ่านบรรทัดคำสั่ง:
rman target /
ตั้งค่าช่วงเวลาตามเวลาที่กำหนด:
กำหนดนโยบายการเก็บรักษาข้อมูลให้มีช่วงเวลาการกู้คืนได้ n วัน;
แทนที่ n ด้วยจำนวนวันตามต้องการที่คุณต้องการให้สามารถกู้คืนข้อมูลได้ เช่น:
กำหนดนโยบายการเก็บรักษาข้อมูลให้มีช่วงเวลากู้คืนได้ 7 วัน;
เพื่อเปลี่ยนไปใช้โหมดนับจำนวนสำเนาแทน:
กำหนดนโยบายการเก็บรักษาให้มีความซ้ำซ้อน n ชุด
โดยที่ n หมายถึงจำนวนสำเนาที่ใช้งานได้ทั้งหมดต่อไฟล์ที่ต้องการ ตัวอย่างเช่น:
กำหนดนโยบายการเก็บรักษาเป็นความซ้ำซ้อน 2;
อยากรู้ไหมว่าตั้งค่าปัจจุบันเป็นอย่างไร? ตรวจสอบได้ทุกเมื่อโดยใช้:
SHOW RETENTION POLICY;
อยากรู้ไหมว่าสิ่งใดจะถูกลบในการรันครั้งต่อไป? ดูก่อนว่าใครมีสิทธิ์โดนลบ:
รายงานล้าสมัย;
ตัวอย่างผลลัพธ์อาจมีลักษณะเช่นนี้:
RMAN> REPORT OBSOLETE;
ชุดสำรองข้อมูลที่ล้าสมัย
-------------------
กุญแจ BS ขนาด ประเภทอุปกรณ์ เวลาที่ใช้ไป เวลาเสร็จสิ้น
------- ---------- ----------- ------------ -------------------
12 1024M DISK 00:01:23 2024-06-01
...
อ็อบเจ็กต์ต่อไปนี้ล้าสมัยแล้ว...
...
สิ่งนี้จะบอกคุณอย่างแม่นยำว่าชุดหรือไฟล์ใดจะหายไปหากมีการลบในขณะนี้ตามกฎปัจจุบัน ซึ่งเป็นการตรวจสอบความปลอดภัยที่สำคัญก่อนการลบอะไรก็ตาม
พร้อมทำความสะอาดแล้วหรือยัง? ปลดปล่อยพื้นที่ได้ทุกเมื่อผ่าน:
DELETE OBSOLETE;
ต้องการรีเซ็ตทุกอย่างกลับค่าเริ่มต้นหรือไม่
กำหนดนโยบายการเก็บข้อมูลล่วงหน้าเป็นค่าว่าง;
ต้องการปิดนโยบายทั้งหมดชั่วคราวหรือไม่ (ไม่แนะนำ ยกเว้นในกรณีพิเศษ)
CONFIGURE RETENTION POLICY TO NONE;
การปกป้องฐานข้อมูล Oracle ด้วย Vinchin Backup & Recovery
นอกจากเครื่องมือในตัวอย่าง RMAN องค์กรต่างๆ ยังหันไปใช้โซลูชันแบบครบวงจรที่ออกแบบมาโดยเฉพาะสำหรับสภาพแวดล้อมระดับองค์กรกันมากขึ้น Vinchin Backup & Recovery ถือเป็นแพลตฟอร์มระดับมืออาชีพที่รองรับฐานข้อมูลหลักในปัจจุบัน เช่น Oracle, MySQL, SQL Server, MariaDB, PostgreSQL, PostgresPro และ TiDB พร้อมคุณสมบัติที่แข็งแกร่งซึ่งออกแบบมาโดยเฉพาะสำหรับผู้ใช้งาน Oracle ที่ต้องการความคุ้มครองขั้นสูงและประสิทธิภาพที่ดียิ่งขึ้น
จุดเด่นสำคัญ ได้แก่ การบีบอัดข้อมูลด้านต้นทางแบบขั้นสูงและการสำรองข้อมูลแบบเพิ่มเติมที่ช่วยเพิ่มประสิทธิภาพการใช้งานพื้นที่จัดเก็บและเร่งความเร็วในการดำเนินการ ความสามารถในการสำรองข้อมูลฐานข้อมูลแบบชุดช่วยปรับให้สภาพแวดล้อมขนาดใหญ่มีความคล่องตัว การบีบอัดข้อมูลหลายระดับที่ยืดหยุ่นสามารถปรับใช้ได้อย่างง่ายดายในงานต่างๆ ในขณะที่นโยบายการเก็บรักษาข้อมูลอย่างละเอียดช่วยรักษามาตรฐานตามข้อกำหนดโดยไม่ต้องมีการแทรกแซงด้วยตนเอง ทั้งหมดนี้ทำงานร่วมกันเพื่อทำให้การบริหารจัดการง่ายขึ้น ขณะเดียวกันก็เพิ่มความน่าเชื่อถือและคุ้มค่าต่อต้นทุนสูงสุด
Vinchin Backup & Recovery มีคอนโซลเว็บที่ใช้งานง่าย ทำให้การปกป้องฐานข้อมูล Oracle เป็นเรื่องง่าย:
ขั้นตอนที่ 1 เลือกฐานข้อมูล Oracle ที่ต้องการสำรองข้อมูล
ขั้นตอนที่ 2 เลือกที่จัดเก็บข้อมูลสำรอง
ขั้นตอนที่ 3 กำหนดกลยุทธ์การสำรองข้อมูลของคุณ
ขั้นตอนที่ 4 ส่งงาน
เป็นที่ยอมรับทั่วโลกด้วยการจัดอันดับลูกค้าสูงสุดในหลากหลายอุตสาหกรรม Vinchin Backup & Recovery มอบการปกป้องระดับองค์กรที่ได้รับความไว้วางใจจากผู้ใช้งานหลายพันรายทั่วโลก —เริ่มต้นการเดินทางของคุณแบบไม่มีความเสี่ยงตั้งแต่วันนี้พร้อมทดลองใช้งานฟรีครบถ้วน 60 วัน โดยคลิกด้านล่าง
คำถามที่พบบ่อยเกี่ยวกับนโยบายการจัดเก็บข้อมูล RMAN
คำถามที่ 1 ทำให้การลบสำรองข้อมูล Oracle ที่ไม่จำเป็นอัตโนมัติได้หรือไม่ โดยไม่ต้องดำเนินการด้วยตนเอง?
ได้ ฝัง DELETE OBSOLETE ลงในสคริปต์ที่กำหนดเวลาโดยใช้ cron (Linux) หรือ Task Scheduler (Windows)
คำถามที่ 2 ทำไมไฟล์บันทึก redo log เก่าบางไฟล์ที่จัดเก็บไว้จึงไม่ถูกลบ แม้ว่าข้อมูลสำรองเต็มรูปแบบที่เก่าที่สุดขอผมถูกลบไปแล้ว?
บันทึกเหล่านั้นยังคงจำเป็นสำหรับชุดข้อมูลเพิ่มเติม/เต็ม/ไฟล์ข้อมูล/ไฟล์ควบคุมที่ยังคงถูกเก็บไว้ภายใต้วัตถุประสงค์การกู้คืนปัจจุบัน จะยังคงอยู่จนกว่าจะไม่จำเป็นจริงๆ ตามกฎนโยบายที่ใช้งานอยู่
คำถามที่ 3 หากนาฬิกาเซิร์ฟเวอร์ของผมเปลี่ยนแปลงอย่างมีนัยสำคัญจะเกิดอะไรขึ้น ช่วงเวลาการกู้คืน (RECOVERY WINDOW) ของผมจะได้รับผลกระทบไหม?
การเปลี่ยนแปลงวันที่/เวลาของระบบหลักอาจทำให้เกิดผลลัพธ์ที่ไม่คาดคิด เนื่องจากการคำนวณช่วงเวลากู้คืน (RECOVERY WINDOW) ขึ้นอยู่กับข้อมูลเวลาที่จัดเก็บไว้ในไฟล์แคตตาล็อกหรือไฟล์ควบคุมอย่างเคร่งครัด
บทสรุป
นโยบายการเก็บรักษา RMAN ที่มีประสิทธิภาพจะช่วยให้ฐานข้อมูล Oracle ได้รับการปกป้องและมีประสิทธิภาพ ทำให้สามารถถ่วงดุลระหว่างความเสี่ยงกับต้นทุน พร้อมทั้งช่วยให้งานจัดการต่าง ๆ เรียบง่ายขึ้นตามกาลเวลา Vinchin พัฒนาหลักการเหล่านี้ด้วยคุณสมบัติขั้นสูงที่ออกแบบมาโดยเฉพาะเพื่อตอบสนองความต้องการด้านการปกป้องระดับองค์กรทั่วโลก
