การสำรองข้อมูลฐานข้อมูลสำรอง Oracle ของคุณโดยใช้ RMAN ไม่ใช่แค่เรื่องฉลาดเท่านั้น แต่ยังจำเป็นอย่างยิ่งต่อการดำเนินงานด้านไอทีในยุคปัจจุบัน โดยการโอนภาระงานสำรองข้อมูลจากระบบหลักที่ทำงานหนักไปยังระบบที่สำรองไว้ คุณจะช่วยลดผลกระทบต่อประสิทธิภาพการทำงานของระบบผลิตจริง ขณะเดียวกันก็ยังคงปกป้องข้อมูลสำคัญได้อย่างมีประสิทธิภาพ แนวทางนี้ช่วยให้ธุรกิจดำเนินต่อไปได้แม้อยู่ในช่วงเวลาที่มีการทำธุรกรรมหนาแน่นหรือเกิดเหตุขัดข้องที่ไม่คาดคิด ในคู่มือนี้ เราจะอธิบายให้เข้าใจง่ายว่า ความหมายของ rman backup standby database ทำไมสิ่งนี้มีความสำคัญต่อแผนการกู้คืนจากภัยพิบัติ และคุณสามารถดำเนินการสำรองข้อมูลเหล่านี้ได้อย่างมั่นใจได้อย่างไร ไม่ว่าระดับทักษะของคุณจะเป็นเช่นไร
RMAN Backup คืออะไร?
RMAN หมายถึง Recovery Manager ซึ่งเป็นเครื่องมือในตัวของ Oracle ที่ออกแบบมาโดยเฉพาะเพื่อทำให้งานสำรองข้อมูลและการกู้คืนฐานข้อมูลเป็นไปโดยอัตโนมัติ โดยใช้ RMAN คุณสามารถสร้างการสำรองข้อมูลแบบเต็มหรือแบบเพิ่มเติมของไฟล์ข้อมูล ไฟล์ควบคุม บันทึก redo log ที่จัดเก็บไว้ และแม้แต่ไฟล์พารามิเตอร์ของเซิร์ฟเวอร์ เนื่องจาก RMAN มีการผสานรวมอย่างแนบแน่นกับ Oracle Database โดยตรง จึงรองรับคุณสมบัติขั้นสูง เช่น การกู้คืนระดับบล็อกและการตรวจสอบความถูกต้องของข้อมูลสำรองอย่างละเอียด สำหรับสภาพแวดล้อม Oracle ส่วนใหญ่ ไม่ว่าจะเป็นธุรกิจขนาดเล็กหรือองค์กรขนาดใหญ่ RMAN ถือว่าเป็นแนวทางปฏิบัติที่ดีที่สุดเนื่องจากมีความน่าเชื่อถือและยืดหยุ่นสูง
Standby Database ใน Oracle คืออะไร?
Standby Database ทำหน้าที่เป็นสำเนาที่ซิงค์ข้อมูลกับดาต้าเบสหลักของคุณอยู่เสมอ โดยจะได้รับการเปลี่ยนแปลงจาก redo log จากระบบหลักผ่านกลไก Data Guard ส่วนใหญ่มักตั้งค่าเป็นสแตนด์บายทางกายภาพ ซึ่งเป็นสำเนาทีละไบต์ที่สามารถเข้ามาดำเนินการแทนได้ทันทีหากเกิดปัญหาขึ้นกับสภาพแวดล้อมหลักของคุณ ขึ้นอยู่กับความต้องการในการกำหนดค่า คุณสามารถรันสแตนด์บายในโหมดการกู้คืนแบบจัดการ หรือเปิดใช้งานในโหมดอ่านอย่างเดียวเพื่อวัตถุประสงค์ในการรายงานโดยไม่กระทบต่อการซิงโครไนซ์
Oracle Data Guard จัดการการสื่อสารทั้งหมดระหว่างฐานข้อมูลหลักและฐานข้อมูลสำรอง เพื่อให้การเปลี่ยนแปลงถูกนำไปใช้ในขั้นตอนต่อไปอย่างรวดเร็ว หากเกิดภัยพิบัติ เช่น ความล้มเหลวของฮาร์ดแวร์ หรือการหยุดทำงานของไซต์ ฐานข้อมูลสำรองสามารถกลายเป็นระบบผลิตภัณฑ์ใหม่ได้ทันทีเกือบจะทันที
ทำไมต้องสำรองข้อมูล Standby Database?
เป็นเรื่องปกติที่จะมีคำถามว่า หากฐานข้อมูลสำรองของผมมีข้อมูลเหมือนกับระบบปฏิบัติการอยู่แล้ว ทำไมต้องสำรองข้อมูลอีกครั้ง คำตอบคือเพื่อความยืดหยุ่นในการรับมือกับความล้มเหลวหลายรูปแบบ และเพื่อประสิทธิภาพในการดำเนินงานประจำวัน
การสำรองข้อมูลออกจากระบบหลักครั้งแรกจะช่วยลดภาระการทำงานของ CPU และการใช้งานดิสก์ I/O บนระบบที่ให้บริการผู้ใช้จริงหรือแอปพลิเคชัน ซึ่งช่วยรักษาประสิทธิภาพการทำงานให้สูงในจุดที่สำคัญที่สุด ขณะเดียวกันก็ยังคงมั่นใจได้ว่าข้อมูลที่สำคัญต่อธุรกิจจะได้รับการปกป้องอย่างสม่ำเสมอ
ประการที่สอง และอาจสำคัญกว่า คือ การสำรองข้อมูลที่ถ่ายโอนมาจากฝั่งใดก็ตาม (หลักหรือสำรอง) สามารถใช้แทนกันได้อย่างสมบูรณ์ เท่าที่การถ่ายโอน redo ยังคงทำงานได้ดี ซึ่งหมายความว่า คุณสามารถกู้คืนระบบใดก็ตามโดยใช้ชุดข้อมูลสำรองที่ถูกต้องไม่ว่าจะสร้างที่ใดก็ตาม นี่เป็นตัวเลือกที่ทรงพลังมากเมื่อวางแผนกลยุทธ์การกู้คืนจากภัยพิบัติที่มีประสิทธิภาพ
ในที่สุดการสำรองข้อมูลทั้งสองฐานข้อมูลช่วยป้องกันเหตุการณ์ที่เกิดขึ้นน้อยแต่ร้ายแรง เช่น ความเสียหายของตรรกะหรือการลบข้อมูลโดยไม่ได้ตั้งใจ ซึ่งอาจแพร่กระจายไปยังทั้งสองไซต์ก่อนที่จะถูกตรวจพบ
ข้อกำหนดเบื้องต้นก่อนการสำรองข้อมูล Oracle Standby Database
ก่อนดำเนินการใดๆ ที่เกี่ยวข้องกับ rman backup standby database ผู้ดูแลระบบควรดำเนินการตรวจสอบสิ่งสำคัญบางประการ สิ่งเหล่านี้จะช่วยป้องกันงานที่ล้มเหลวหรือการกู้คืนข้อมูลที่ไม่สมบูรณ์ในเวลาต่อมา
เริ่มต้นด้วยการยืนยันว่าอินสแตนซ์เป้าหมายของคุณทำหน้าที่เป็นสแตนด์บายทางกายภาพจริง ๆ ไม่ใช่แค่อีกสภาพแวดล้อมทดสอบหนึ่ง
1. เชื่อมต่อกับ SQL*Plus บนโฮสต์ที่ตั้งใจไว้
2. รัน SELECT DATABASE_ROLE, OPEN_MODE FROM V$DATABASE;
3. ตรวจสอบให้แน่ใจว่าผลลัพธ์แสดง PHYSICAL STANDBY ภายใต้ DATABASE_ROLE
4. ยืนยันว่า OPEN_MODE แสดงค่า MOUNTED (สำหรับการกู้คืนแบบจัดการ) หรือ READ ONLY WITH APPLY (หากเปิดในโหมดอ่านอย่างเดียว)
ตรวจสอบขั้นตอนต่อไปเกี่ยวกับการหน่วงเวลาในการทำสำเนาระหว่างระบบหลักกับระบบทดสอบ:
1. สอบถาม SELECT APPLIED_SEQ#, LATEST_SEQ# FROM V$ARCHIVE_DEST_STATUS WHERE DEST_ID=2;
2. เปรียบเทียบตัวเลข ความแตกต่างที่ชัดเจนหมายความว่าเรายังไม่ได้นำไฟล์ redo log บางส่วนมาใช้
3. ถ้ามีความล่าช้า ให้รอจนกว่าการซิงโครไนซ์จะเสร็จสิ้นก่อนเริ่มการสำรองข้อมูล
โปรดยืนยันด้วยว่าไฟล์ควบคุมของคุณถูกสร้างขึ้นโดยเฉพาะสำหรับ "STANDBY" สิ่งนี้จะช่วยให้มั่นใจได้ว่าเข้ากันได้เมื่อทำการกู้คืนในภายหลัง:
1. จาก SQL*Plus รันคำสั่ง SHOW PARAMETER CONTROL_FILES เพื่อค้นหาตำแหน่งของไฟล์คอนโทรลปัจจุบัน
2. ใช้ BACKUP CURRENT CONTROLFILE FOR STANDBY; ก็ต่อเมื่อแน่ใจว่าชนิดของไฟล์นี้ตรงตามข้อกำหนด
การใช้เวลาในการตรวจสอบสิ่งเหล่านี้อย่างง่ายจะช่วยประหยัดเวลาหลายชั่วโมงจากการแก้ปัญหาการกู้คืนที่ล้มเหลวในอนาคต!
วิธีการใช้ RMAN สำหรับการสำรองข้อมูล Standby Database
เมื่อปฏิบัติตามข้อกำหนดเบื้องต้นครบถ้วนแล้ว คุณก็จะพร้อมเริ่มการสำรองข้อมูลอย่างมั่นใจโดยใช้คำสั่ง RMAN ที่ปรับแต่งมาเฉพาะสำหรับโหมด standby
1. เชื่อมต่อกับ Standby Database
ควรเชื่อมต่อโดยใช้ข้อมูลรับรองที่ชัดเจนเสมอ แทนการพึ่งพาการตรวจสอบสิทธิ์ของระบบปฏิบัติการเพียงอย่างเดียว หากคุณใช้การตรวจสอบสิทธิ์ของระบบปฏิบัติการ (rman target /) RMAN จะไม่สามารถเรียกใช้การสลับลอจได้ในฐานข้อมูลหลัก ซึ่งหมายความว่าธุรกรรมล่าสุดอาจไม่ถูกรวมไว้ในการสำรองบันทึกการเก็บถาวร
ให้เริ่มเซสชันที่ผ่านการรับรองตัวตนแทน:
rman target sys/<password>
แทนที่ <password> ด้วยรหัสผ่านผู้ใช้ SYS จริงของคุณที่นี่ ไม่ใช่เครื่องหมายขีดทับว่างๆ เพียงเท่านั้น วิธีนี้ทำให้ RMAN เข้าถึงได้อย่างเต็มที่ตลอดทั้งสองโหนด ทำให้บันทึกทั้งหมดที่จำเป็นสลับอย่างถูกต้องระหว่างการทำงานสำรองข้อมูล
2. เริ่มการสำรองข้อมูล
เพื่อจับภาพทุกอย่าง รวมถึงไฟล์บันทึกที่เก็บไว้ทั้งหมดและไฟล์ข้อมูลปัจจุบัน ให้รันคำสั่งนี้ภายใน RMAN:
BACKUP DATABASE PLUS ARCHIVELOG;
คำสั่งเพียงบรรทัดเดียวนี้จะสั่งให้ Recovery Manager สำรองข้อมูลไฟล์ข้อมูลทุกไฟล์พร้อมกับไฟล์บันทึก redo ที่ถูกเก็บไว้ทั้งหมด ณ เวลานั้นบนดิสก์ แม้แต่ไฟล์ที่สร้างขึ้นระหว่างการดำเนินการก็ตาม เนื่องจากมีการเปิดใช้งานการสลับบันทึกอัตโนมัติผ่านการเชื่อมต่อแบบใช้รหัสผ่าน
3. สำรองไฟล์คอนโทรลของระบบที่อยู่ในสถานะสำรอง
เพื่อความสามารถในการกู้คืนข้อมูลสูงสุด ให้รวมภาพถ่ายของไฟล์คอนโทรลที่เหมาะสมสำหรับการกู้คืนในอนาคตไว้เสมอ:
BACKUP CURRENT CONTROLFILE FOR STANDBY;
สิ่งนี้จะสร้างเวอร์ชันพิเศษที่เข้ากันได้กับขั้นตอนการติดตั้งใหม่ในภายหลัง หากเกิดภัยพิบัติขึ้นอย่างไม่คาดคิดที่ไซต์ใดไซต์หนึ่ง
4. ตรวจสอบข้อผิดพลาด
หลังจากเริ่มงานสำรองข้อมูลหลักใดๆ อย่าถือว่าสำเร็จโดยไม่ได้ตรวจสอบผลลัพธ์อย่างละเอียด โดยเฉพาะคำเตือนต่างๆ เช่น
RMAN-06820: คำเตือน: ไม่สามารถจัดเก็บบันทึกปัจจุบันไว้ที่ฐานข้อมูลหลัก
ข้อความนี้แสดงว่าการสลับลอจไม่สำเร็จ มักเป็นเพราะใช้การพิสูจน์ตัวตนของระบบปฏิบัติการแทนรหัสผ่านในระหว่างการตั้งค่าการเชื่อมต่อในขั้นตอนที่ 1 ข้างต้น
นอกจากข้อผิดพลาดที่เห็นได้ชัด ให้ตรวจสอบบันทึกงานภายใน RMAN เอง (SHOW ALL) รวมถึงบันทึกแจ้งเตือนที่เกี่ยวข้องผ่านคำสั่ง SQL*Plus เช่น:
SELECT * FROM V$DIAG_ALERT_EXT WHERE ORIGINATING_TIMESTAMP > SYSDATE - 1;
พิจารณาเรียกใช้คำสั่งวินิจฉัยหลังจากดำเนินการเสร็จด้วย
ล้มเหลวในการแสดงรายการ;
ADVISE FAILURE;
สิ่งเหล่านี้ช่วยตรวจจับปัญหาที่อาจเกิดขึ้น เช่น บล็อกที่เสียหายซึ่งถูกตรวจพบระหว่างการสำรองข้อมูล ซึ่งมิฉะนั้นอาจไม่ได้รับการสังเกตเห็นจนกว่าจะถึงเวลาคืนข้อมูล
5. สำรองข้อมูลบันทึกการจัดเก็บอีกครั้ง
หากช่วงเวลาทำงานต่อเนื่องยาวนานกว่าที่คาดไว้ หรือหากการกู้คืนข้อมูล ณ เวลาหนึ่งๆ มีความสำคัญมาก คุณอาจต้องการความมั่นใจเพิ่มเติมโดยการบันทึกไฟล์บันทึกการจัดเก็บเพิ่มเติมที่สร้างขึ้นตั้งแต่เริ่มทำภาพถ่ายข้อมูลครั้งแรก:
BACKUP ARCHIVELOG ALL NOT BACKED UP 1 TIMES;
การเรียกใช้คำสั่งนี้ทันทีหลังจากงานหลักเสร็จสิ้น จะช่วยให้มั่นใจได้ว่าไม่มีกิจกรรมใดๆ ล่าช้าเนื่องจากระยะเวลาห่างระหว่างขั้นตอนด้านบน!
6. ตรวจสอบความถูกต้องของข้อมูลสำรอง
อย่าข้ามขั้นตอนการตรวจสอบเด็ดขาด! แม้งานสำรองข้อมูลที่ดูเหมือนสำเร็จก็อาจสร้างไฟล์ที่ใช้ไม่ได้ในบางครั้ง เนื่องจากปัญหาฮาร์ดแวร์หรือความเสียหายที่เกิดขึ้นโดยไม่รู้ตัวในเบื้องหลัง:
รันภายในพรอมต์ RMAN:
RESTORE DATABASE VALIDATE;
กระบวนการนี้จำลองการกู้คืนโดยไม่ได้เขียนทับข้อมูลใดๆ ทำให้มั่นใจได้ว่าส่วนประกอบทั้งหมดที่ต้องการมีอยู่ครบถ้วนภายในที่เก็บข้อมูล ซึ่งตอนนี้จัดเก็บไว้อย่างปลอดภัยในสถานที่นอกไซต์ (หรือตามที่นโยบายกำหนด)
7. กู้คืนจากรองสำรอง
หากเกิดวิกฤตที่จำเป็นต้องกู้คืนระบบการผลิตจากชุดข้อมูลที่ถ่ายโอนออกไป ให้ปฏิบัติตามขั้นตอนมาตรฐานสำหรับการกู้คืนข้ามเซิร์ฟเวอร์
1) คัดลอกไฟล์ที่เกี่ยวข้องไปยังโฮสต์ปลายทางอย่างปลอดภัยผ่านจุดเชื่อมต่อ NFS การถ่ายโอน SCP เป็นต้น
2) เริ่มการลงทะเบียนแคตตาล็อกเพื่อให้ตัวอย่างในท้องถิ่นจดจำได้:
CATALOG เริ่มต้นด้วย '<path_to_backup_pieces_on_primary>';
3) ดำเนินการผ่านเวิร์กโฟลว์ RESTORE / RECOVER ตามปกติ ตามเอกสารประกอบโดยทั่วไป
โปรดจำไว้: ตราบใดที่การขนส่งซ้ำยังคงดำเนินต่ออย่างไม่ขัดข้องตลอดรอบก่อนหน้า ชุดเหล่านี้จะยังคงมีผลเต็มที่โดยไม่คำนึงถึงสถานที่ต้นทาง
การปกป้องฐานข้อมูล Oracle ด้วย Vinchin Backup & Recovery
สำหรับองค์กรที่ต้องการระบบอัตโนมัติที่มีประสิทธิภาพเหนือกว่าการเขียนสคริปต์ด้วยตนเอง โซลูชันระดับองค์กรมอบข้อได้เปรียบที่สำคัญเมื่อมีการป้องกันฐานข้อมูลสำคัญ เช่น สภาพแวดล้อม Oracle ที่กล่าวมาข้างต้น
Vinchin Backup & Recovery เป็นแพลตฟอร์มระดับองค์กรระดับมืออาชีพที่รองรับฐานข้อมูลหลักในปัจจุบัน ได้แก่ Oracle, MySQL, SQL Server, MariaDB, PostgreSQL, PostgresPro และ TiDB พร้อมคุณสมบัติครบถ้วนที่ออกแบบมาเพื่อการปกป้องอย่างมีประสิทธิภาพ
คุณสมบัติหลัก ได้แก่ การสนับสนุนการสำรองข้อมูลแบบเพิ่มเติม การจัดการการสำรองข้อมูลฐานข้อมูลแบบกลุ่มพร้อมกันหลายอินสแตนซ์ นโยบายการเก็บรักษารูปแบบ GFS ที่ยืดหยุ่นเพื่อรับรองรอบการจัดเก็บที่เป็นไปตามข้อกำหนด เทคโนโลยีการบีบอัดข้อมูล/การลดความซ้ำซ้อนของข้อมูลเพื่อเพิ่มประสิทธิภาพการใช้พื้นที่จัดเก็บ และกลไกตรวจสอบความสมบูรณ์เพื่อยืนยันความสามารถในการกู้คืนก่อนที่ภัยพิบัติจะเกิดขึ้น ฟีเจอร์เหล่านี้ร่วมกันช่วยให้เกิดการใช้ทรัพยากรอย่างมีประสิทธิภาพ การควบคุมดูแลแบบรวมศูนย์ และตัวเลือกการกู้คืนที่เชื่อถือได้และรวดเร็ว ซึ่งล้วนแต่สำคัญต่อภาระงานที่จำเป็นต่อภารกิจ
คอนโซลเว็บแบบเข้าใจง่ายทำให้การปกป้องฐานข้อมูล Oracle เป็นเรื่องง่าย:
ขั้นตอนที่ 1 เลือกฐานข้อมูล Oracle ที่ต้องการสำรองข้อมูล
ขั้นตอนที่ 2 เลือกที่จัดเก็บข้อมูลสำรองที่ต้องการ
ขั้นตอนที่ 3 กําหนดพารามิเตอร์เกี่ยวกับการจัดตาราง การเก็บรักษา และกลยุทธ์อื่น ๆ
ขั้นตอนที่ 4 ส่งงาน ทั้งหมดภายในไม่กี่นาทีผ่านอินเทอร์เฟซเบราว์เซอร์ที่ใช้งานง่าย
Vinchin Backup & Recovery ได้รับความไว้วางใจจากองค์กรต่างๆ ทั่วโลกนับพันแห่ง และได้รับคะแนนสูงสุดจากนักวิเคราะห์อุตสาหกรรม นำเสนอการดาวน์โหลดทดลองใช้งานฟีเจอร์ครบถ้วนแบบไม่มีความเสี่ยง 60 วันด้านล่างนี้ เพื่อให้คุณได้สัมผัสประสบการณ์การปกป้องข้อมูลระดับแนวหน้าด้วยตัวเอง
คำถามที่พบบ่อยเกี่ยวกับการสำรองข้อมูลฐานข้อมูลสำรองด้วย RMAN
คำถามที่ 1 ผมสามารถใช้การสำรองข้อมูล RMAN จากฐานข้อมูลสำรองเพื่อกู้คืนสภาพแวดล้อมการผลิตของผมได้ไหม?
ได้ ตราบเท่าที่การถ่ายโอนซ้ำยังคงทำให้ทั้งสองฝั่งซิงค์โครนัสกัน เซ็ตเหล่านี้สามารถใช้งานสลับกันระหว่างบทบาทได้โดยไม่มีปัญหา
คำถามที่ 2 หากผมสำรองข้อมูลเซิร์ฟเวอร์สำรองของผมโดยใช้การตรวจสอบสิทธิ์ของระบบปฏิบัติการแทนการป้อนข้อมูลประจำตัว จะเกิดอะไรขึ้น?
RMAN จะไม่สลับบันทึกปัจจุบันโดยอัตโนมัติ ดังนั้นธุรกรรมล่าสุดอาจไม่ปรากฏในไฟล์เก็บผลลัพธ์; ควรระบุชื่อผู้ใช้/รหัสผ่านอย่างชัดเจนเสมอเมื่อเชื่อมต่อ!
คำถามที่ 3 ผมควรตั้งตารางการทำสำรองข้อมูลแบบเต็มและแบบเพิ่มเติมจากระบบสแตนด์บายของผมบ่อยแค่ไหน?
จับคู่ความถี่กับเป้าหมาย RPO ทางธุรกิจ ตัวอย่างเช่น การสำรองข้อมูลแบบเต็มรายสัปดาห์พร้อมการเพิ่มข้อมูลรายวันควบคู่ไปกับการจับภาพไฟล์บันทึกเก็บถาวรบ่อยครั้ง จะช่วยเพิ่มการปกป้องข้อมูลได้สูงสุด ในขณะที่ลดการใช้ทรัพยากรโดยรวม
บทสรุป
การสำรองข้อมูลฐานข้อมูลสำรอง Oracle ด้วย RMAN จะช่วยเพิ่มความทนทานและลดภาระของระบบหลัก โดยต้องไม่ลืมตรวจสอบยืนยันสิทธิ์ รายละเอียดแคตตาล็อก และปฏิบัติตามแนวทางที่ดีที่สุดระหว่างดำเนินการ Vinchin ช่วยให้การปกป้องข้อมูลง่ายยิ่งขึ้นด้วยระบบอัตโนมัติที่ออกแบบมาโดยเฉพาะตามความต้องการขององค์กร หากคุณสนใจความปลอดภัยที่เรียบง่าย ลองใช้งานฟรีได้วันนี้
