ความต่อเนื่องทางธุรกิจขึ้นอยู่กับความสามารถของคุณในการกู้คืนอย่างรวดเร็วเมื่อเกิดปัญหา สำหรับหลายองค์กร เช่น ธนาคารหรือเว็บไซต์อีคอมเมิร์ซ แม้แต่การหยุดทำงานเพียงไม่กี่นาทีก็อาจหมายถึงรายได้หรือความไว้วางใจที่สูญเสียไป หนึ่งในวิธีที่พิสูจน์แล้วว่าสามารถรักษาความปลอดภัยของข้อมูลคือการทำซ้ำฐานข้อมูลเป้าหมายเพื่อใช้เป็นฐานข้อมูลสแตนด์บายจากฐานที่กำลังใช้งานอยู่ โดยใช้เครื่องมือในตัวจาก Oracle บทความนี้จะอธิบายว่าสิ่งนี้หมายถึงอะไร ทำไมสำคัญ สิ่งที่คุณต้องเตรียมล่วงหน้า จากนั้นจะแนะนำวิธีมาตรฐานสองวิธี ได้แก่ RMAN และ Data Guard
Duplicating Target Database สำหรับโหมดสแตนด์บายคืออะไร
การทำซ้ำฐานข้อมูลเป้าหมาย สำหรับโหมดสแตนด์บาย หมายถึงการสร้างสำเนางานของฐานข้อมูล Oracle หลัก (ระบบปฏิบัติการ) บนเซิร์ฟเวอร์หรือไซต์อื่น โดยฐานข้อมูลสแตนด์บายนี้จะคงสถานะการซิงค์ข้อมูลกับระบบหลักอย่างใกล้เคียงเรียลไทม์ หากเกิดภัยพิบัติ เช่น ความล้มเหลวของฮาร์ดแวร์หรือข้อมูลเสียหาย คุณสามารถสลับการทำงานไปยังฐานข้อมูลสแตนด์บายนี้ได้โดยมีเวลาหยุดทำงานหรือสูญเสียข้อมูลในระดับต่ำที่สุด
กระบวนการนี้ใช้คุณสมบัติในตัวของ Oracle เพื่อให้การเปลี่ยนแปลงที่ทำบนระบบหลักถูกส่งไปยังระบบสำรองโดยอัตโนมัติ การตั้งค่านี้มีความสำคัญอย่างยิ่งในสภาพแวดล้อมที่ต้องการความพร้อมใช้งานสูง ซึ่งทุกธุรกรรมมีความสำคัญ
ทำไมต้องสร้างฐานข้อมูลสแตนด์บายจากฐานข้อมูลหลัก?
ฐานข้อมูลสแตนด์บายทำหน้าที่เป็นเครือข่ายความปลอดภัยของคุณจากการเกิดเหตุการณ์ไม่คาดฝัน เช่น การล่มของฮาร์ดแวร์ หรือภัยพิบัติทางธรรมชาติ โดยการจำลองข้อมูลโดยตรงจากฐานข้อมูลหลักแทนการกู้คืนจากสำเนาข้อมูลเก่า ทำให้คุณสามารถจับภาพการเปลี่ยนแปลงล่าสุดได้ทั้งหมดโดยไม่พลาดสิ่งสำคัญใดๆ
แนวทางนี้ช่วยลดเวลาการกู้คืนข้อมูล เนื่องจากไม่ต้องกู้คืนไฟล์สำรองขนาดใหญ่ก่อน ข้อมูลจะไหลโดยตรงระหว่างเซิร์ฟเวอร์ผ่านเครือข่ายในระหว่างการทำซ้ำ นอกจากนี้ยังรองรับแผนการดำเนินธุรกิจอย่างต่อเนื่องที่องค์กรสมัยใหม่ต้องการ ซึ่งไม่สามารถยอมรับการหยุดทำงานนานหรือทำรายการสูญหายได้
ข้อกำหนดล่วงหน้าและแนวทางปฏิบัติที่ดีที่สุด
ก่อนที่คุณจะเริ่มทำซ้ำฐานข้อมูลเป้าหมายของคุณเพื่อใช้เป็นสำรองจากฐานข้อมูลหลัก ควรใช้เวลาวางแผนอย่างรอบคอบ
ขั้นตอนแรก ตรวจสอบว่าเซิร์ฟเวอร์หลักและเซิร์ฟเวอร์สำรองใช้เวอร์ชัน Oracle ที่เข้ากันได้และมีระดับแพตช์ตรงกัน เพราะความไม่ตรงกันอาจทำให้เกิดข้อผิดพลาดในภายหลัง จากนั้นตรวจสอบให้มั่นใจว่ามีแบนด์วิธเครือข่ายเพียงพอระหว่างไซต์ เนื่องจากข้อมูลทั้งหมดจะต้องถูกถ่ายโอนผ่านลิงก์นี้ เครือข่ายที่ช้าลงหมายถึงเวลาการทำซ้ำที่นานขึ้น
การจัดวางโครงสร้างพื้นที่เก็บข้อมูลก็มีความสำคัญเช่นกัน หากคุณใช้ ASM ฝั่งหนึ่งแต่ใช้ระบบไฟล์อีกฝั่งหนึ่ง หรือหากพาธไดเรกทอรีต่างกัน คุณต้องตั้งค่าพารามิเตอร์การแปลงให้ถูกต้องในระหว่างการติดตั้ง (อธิบายด้านล่าง) ควรตรวจสอบพื้นที่ดิสก์ทั้งสองฝั่งเสมอ การหมดพื้นที่กลางกระบวนการจะทำให้เซิร์ฟเวอร์สำรองไม่สมบูรณ์
เปิดใช้งานเครื่องมือตรวจสอบก่อนเริ่มต้นเพื่อให้คุณสามารถติดตามความคืบหน้าและตรวจพบปัญหาได้แต่เนิ่นๆ แม้แต่การตรวจสอบบันทึกการแจ้งเตือนพื้นฐานก็ช่วยให้สามารถจับปัญหาได้อย่างรวดเร็วหลังจากทำซ้ำเสร็จสิ้น
สุดท้าย อย่าลืมทดสอบในสภาพแวดล้อมที่ไม่ใช่การผลิตก่อนเสมอ การฝึกฝนทำให้เชี่ยวชาญ และช่วยป้องกันเหตุไม่คาดคิดเมื่อถึงเวลาสำคัญ
วิธีที่ 1. การทำซ้ำฐานข้อมูลเป้าหมายโดยใช้ RMAN
RMAN (Recovery Manager) เป็นเครื่องมือในตัวของ Oracle สำหรับงานการสำรองข้อมูลและการกู้คืน รวมถึงการสร้างระบบที่อยู่แล้วโดยตรงจากแหล่งที่มาที่ทำงานอยู่ โดยไม่ต้องมีไฟล์สำรองแยกต่างหากก่อน
นี่คือวิธีการทำซ้ำฐานข้อมูลเป้าหมายเพื่อใช้สำรองด้วย RMAN:
เริ่มต้นด้วยการตรวจสอบว่าระบบหลักของคุณทำงานในโหมด ARCHIVELOG โดยเปิดใช้งาน FORCE LOGGING เพื่อให้มั่นใจว่าทุกการเปลี่ยนแปลงจะถูกบันทึกอย่างเชื่อถือได้:
ตรวจสอบโหมดเก็บถาวร:
SQL> archive log list
ถ้าไม่ได้เปิดใช้งาน:
SQL> SHUTDOWN IMMEDIATE
SQL> STARTUP MOUNT
SQL> ALTER DATABASE ARCHIVELOG;
SQL> ALTER DATABASE OPEN;
เปิดการบันทึกแบบบังคับ:
SQL> ALTER DATABASE FORCE LOGGING;
ตั้งค่าพารามิเตอร์ Data Guard หลัก:
SQL> ALTER SYSTEM SET LOG_ARCHIVE_CONFIG='DG_CONFIG=(primary,standby)';
SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_1='LOCATION=/path/to/arch VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=primary';
SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_2='SERVICE=standby LGWR ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=standby';
SQL> ALTER SYSTEM SET FAL_SERVER=standby;
SQL> ALTER SYSTEM SET FAL_CLIENT=primary;
SQL> ALTER SYSTEM SET STANDBY_FILE_MANAGEMENT=AUTO;
การตั้งค่านี้ควบคุมวิธีการส่งลอกระหว่างเซิร์ฟเวอร์ ปรับเส้นทางตามความจำเป็นตามโครงสร้างสภาพแวดล้อมของคุณ
ในเซิร์ฟเวอร์สำรอง: ติดตั้งเวอร์ชัน Oracle เดียวกัน กำหนดค่าไฟล์เครือข่าย (listener.ora, tnsnames.ora) เพื่อให้ทั้งสองฝั่งสื่อสารกันได้อย่างราบรื่น คัดลอกไฟล์รหัสผ่านมา สร้างไดเรกทอรีให้ตรงกับที่ใช้โดย datafile/log/folder การจัดการของเซิร์ฟเวอร์หลัก หากมีความแตกต่างกันแม้เพียงเล็กน้อย (มิฉะนั้น DB_FILE_NAME_CONVERT/LOG_FILE_NAME_CONVERT จะมีความสำคัญมาก)
สร้างไฟล์เริ่มต้นขั้นต่ำ (initstandby.ora) ที่มีอย่างน้อย DB_NAME พร้อมการตั้งค่าชื่อเฉพาะ:
db_name='yourdbname'
db_unique_name='standby'
...
เริ่มต้นอินสแตนซ์ในโหมด NOMOUNT:
SQL> STARTUP NOMOUNT PFILE='/path/to/initstandby.ora';
ตอนนี้เชื่อมต่อผ่าน RMAN จากเซิร์ฟเวอร์ใดเซิร์ฟเวอร์หนึ่ง:
$ rman TARGET sys/password@primary AUXILIARY sys/password@standby
เรียกใช้บล็อกคำสั่งนี้ (แก้ไขพาธ/ชื่อตามที่จำเป็น):
RMAN> RUN {
ALLOCATE CHANNEL prmy1 TYPE DISK;
ALLOCATE CHANNEL prmy2 TYPE DISK;
ALLOCATE AUXILIARY CHANNEL stby TYPE DISK;
DUPLICATE TARGET DATABASE FOR STANDBY FROM ACTIVE DATABASE
SPFILE
PARAMETER_VALUE_CONVERT 'primary','standby'
SET DB_UNIQUE_NAME='standby'
SET DB_FILE_NAME_CONVERT='/primary/datafile','/standby/datafile'
SET LOG_FILE_NAME_NAME_CONVERT='/primary/onlinelog','/standby/onlinelog'
SET CONTROL_FILES='/path/to/standby/control01.ctl'
SET FAL_CLIENT='standby'
SET FAL_SERVER='primary'
SET LOG_ARCHIVE_CONFIG='DG_CONFIG=(primary,standby)'
SET LOG_ARCHIVE_DEST_1='LOCATION=/path/to/standby/arch'
SET LOG_ARCHIVE_DEST_2='SERVICE=primary ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=primary'
SET STANDBY_FILE_MANAGEMENT='AUTO'
NOFILENAMECHECK;
}ตัวเลือกเหล่านี้ทำอะไร? ก็บอก RMAN ว่าจะแมปตำแหน่งไฟล์ระหว่างเซิร์ฟเวอร์อย่างไร (_CONVERT) ตั้งชื่อเฉพาะเพื่อไม่ให้บทบาทซ้อนทับกัน (DB_UNIQUE_NAME) กำหนดว่าล็อกจะถูกส่งไปที่ใด (LOG_ARCHIVE_) เปิดใช้งานการจัดการไฟล์ใหม่โดยอัตโนมัติ (STANDBY_FILE_MANAGEMENT=AUTO) และข้ามการตรวจสอบชื่อไฟล์หากโครงสร้างไดเรกทอรีต่างกัน (NOFILENAMECHECK) ปรับค่าตามโครงสร้างไดเรกทอรีจริงของคุณ
เมื่อคัดลอกไฟล์/การตั้งค่าเสร็จสิ้นโดยอัตโนมัติ
เริ่มการกู้คืนที่จัดการที่พรอมต์สำรอง:
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;
วิธีที่ 2. การทำสำเนาฐานข้อมูลเป้าหมายด้วย Data Guard
Oracle Data Guard ทำให้งานต่างๆ ที่ปกติแล้วคุณต้องดำเนินการด้วยตนเองผ่าน RMAN อัตโนมัติ และยังเพิ่มความสามารถในการตรวจสอบ การสลับโหมด และการเปลี่ยนเส้นทางอัตโนมัติ เหมาะอย่างยิ่งสำหรับสภาพแวดล้อมขนาดใหญ่ที่ต้องการคุณสมบัติด้านความพร้อมใช้งานสูงอย่างแข็งแกร่ง
1. ตรวจสอบความสอดคล้องของสภาพแวดล้อม
ก่อนเริ่มต้น โปรดตรวจสอบให้แน่ใจว่าเซิร์ฟเวอร์หลักและเซิร์ฟเวอร์สำรองมีค่าตรงกันใน
ประเภทระบบปฏิบัติการ
เวอร์ชันฐานข้อมูล Oracle
ระดับแพตช์
2. กำหนดค่าเครือข่าย
ตั้งค่า listener.ora และ tnsnames.ora บนเซิร์ฟเวอร์ทั้งสองเครื่อง เพื่อให้ฐานข้อมูลแต่ละแห่งสามารถตรวจจับและเชื่อมต่อกับชื่อบริการที่ใช้สำหรับการส่งลอกรีดูได้
3. เตรียมไฟล์และไดเรกทอรีที่ต้องใช้
คัดลอกไฟล์รหัสผ่านจากเซิร์ฟเวอร์หลักไปยังเซิร์ฟเวอร์สำรอง เช่นเดียวกับขั้นตอนก่อนหน้า
สร้างไดเรกทอรีหรือระบบแฟ้มข้อมูลที่จำเป็นบนเซิร์ฟเวอร์สำรองล่วงหน้า โดยเฉพาะอย่างยิ่งหากการจัดวางพื้นที่จัดเก็บข้อมูลแตกต่างกันระหว่างสองไซต์
4. ตั้งค่าพารามิเตอร์ Data Guard
ในฐานะ หลัก ให้กำหนดพารามิเตอร์ Data Guard โดยใช้คำสั่งเดียวกันที่แสดงไว้ก่อนหน้าในวิธีที่ 1
ในฐานะ สำรอง ให้แน่ใจว่าพารามิเตอร์ต่อไปนี้ถูกตั้งค่าอย่างถูกต้องสำหรับเงื่อนไขในพื้นที่
5. สร้าง Redo และ Standby Redo Logs ที่เพียงพอ
ข้อกำหนดหลัก: เซิร์ฟเวอร์สำรองต้องมี กลุ่ม redo log มากกว่าเซิร์ฟเวอร์หลักอย่างน้อยหนึ่งกลุ่ม
กลุ่ม redo และกลุ่ม standby redo ทั้งหมดจะต้องมีขนาดเท่ากัน
ตัวอย่าง:
หากฐานข้อมูลหลักใช้กลุ่มบันทึก redo ออนไลน์สามกลุ่ม กลุ่มละ 200 MB
ฐานข้อมูลสำรองควรมี สี่ กลุ่มขนาดกลุ่มละ 200 MB เท่ากัน
SQL> ALTER DATABASE ADD STANDBY LOGFILE '/path/to/redo01.log' SIZE 200M;-- Add remaining groups as required
6. เริ่มต้นอินสแตนซ์สำรองในโหมด NOMOUNT
เริ่มต้นอินสแตนซ์สำรองโดยใช้ PFILE ขั้นต่ำ:
STARTUP NOMOUNT;
7. รันคำสั่ง RMAN Duplicate พร้อมตัวเลือก Data Guard
เชื่อมต่อผ่าน RMAN เช่นเดียวกับที่เคยทำมาก่อน:
$ rman TARGET sys/password@primary AUXILIARY sys/password@standby
จากนั้นเรียกใช้คำสั่ง Data Guard duplicate ที่รวมไว้:
RMAN> DUPLICATE TARGET DATABASE FOR STANDBY
FROM ACTIVE DATABASE
DORECOVER
NOFILENAMECHECK;
8. เปิดใช้งานการกู้คืนที่จัดการ
เมื่อกระบวนการทำซ้ำเสร็จสิ้น:
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;
9. การซิงค์จอภาพ
ตรวจสอบการซิงโครไนซ์และสถานะอย่างสม่ำเสมอ:
SELECT PROCESS, STATUS FROM V$MANAGED_STANDBY;SELECT SEQUENCE#, APPLIEDFROM V$ARCHIVED_LOGORDER BY SEQUENCE# DESCFETCH FIRST 10 ROWS ONLY;SHOW PARAMETER db_unique_name; -- Confirm correct roles
การสำรองข้อมูลและการย้ายฐานข้อมูลสำหรับโหมดสแตนด์บายด้วย Vinchin
สำหรับองค์กรที่ต้องการแนวทางที่ง่ายขึ้นโดยไม่ต้องเขียนสคริปต์ด้วยตนเอง Vinchin Backup & Recovery ให้โซลูชันระดับองค์กรที่ออกแบบมาโดยเฉพาะเพื่อการสำรองข้อมูลและการย้ายฐานข้อมูลชั้นนำในปัจจุบัน ได้แก่ Oracle, MySQL, SQL Server, MariaDB, PostgreSQL, PostgresPro และ TiDB โดยมีการสนับสนุนอย่างครอบคลุมสำหรับสภาพแวดล้อมของ Oracle ซึ่งถูกเน้นไว้อย่างชัดเจนที่นี่
ความสามารถอันหลากหลาย ได้แก่ การดำเนินการสำรองข้อมูลฐานข้อมูลแบบชุด ตัวเลือกการสำรองข้อมูลเพิ่มเติมที่ออกแบบมาเฉพาะสำหรับแพลตฟอร์มบางตัวเช่น Oracle เอง กลยุทธ์การบีบอัดข้อมูลหลายระดับ นโยบายการเก็บรักษาที่แข็งแกร่งรวมถึงการสนับสนุนนโยบายการเก็บรักษา GFS และการบีบอัดที่ต้นทางขั้นสูงเมื่อสามารถใช้ได้ ทั้งหมดนี้ทำงานร่วมกันเพื่อเพิ่มประสิทธิภาพสูงสุดในขณะที่ลดความเสี่ยงให้น้อยที่สุดในโครงสร้างพื้นฐานที่หลากหลาย
Vinchin Backup & Recovery โดดเด่นด้วยคอนโซลเว็บที่ใช้งานง่าย ทำให้การปกป้องสภาพแวดล้อม Oracle ง่ายมาก
ขั้นตอนที่ 1 เลือกฐานข้อมูล Oracle ที่ต้องการสำรองข้อมูล
ขั้นตอนที่ 2 เลือกที่จัดเก็บข้อมูลสำรองที่คุณต้องการ
ขั้นตอนที่ 3 กำหนดกลยุทธ์การสำรองข้อมูลที่ปรับแต่งตามความต้องการ
ขั้นตอนที่ 4 ส่งงาน
ไว้วางใจจากผู้ใช้งานองค์กรระดับโลกหลายพันราย และติดอันดับต้น ๆ ด้านโซลูชันสำรองข้อมูลอย่างต่อเนื่อง Vinchin Backup & Recovery พร้อมให้คุณทดลองใช้งานฟรี เต็มฟังก์ชัน 60 วัน คลิกด้านล่างเพื่อเริ่มใช้งานเลยวันนี้
คำถามที่พบบ่อยเกี่ยวกับการทำซ้ำฐานข้อมูลเป้าหมายสำหรับโหมดสแตนด์บาย
คำถามที่ 1. ใช้เวลานานเท่าไรในการทำสำซ้ำฐานข้อมูลเป้าหมายของผมสำหรับโหมดสแตนด์บายจากแหล่งที่มาที่กำลั้งใช้งานอยู่?
เวลาขึ้นอยู่กับขนาดข้อมูลทั้งหมดและอัตราความเร็วของเครือข่ายที่มีอยู่เป็นหลัก ตัวอย่างเช่น การนำจำนวนรวมของกิกะไบต์หารด้วยเมกะไบต์ต่อวินาทีจะให้ระยะเวลาโดยประมาณต่อชั่วโมงในการถ่ายโอนแบบครบวงจร
คำถามที่ 2. ใช้วิธีการเหล่านี้กับฐานข้อมูล RAC แบบคลัสเตอร์ได้ไหม?
ทำได้ แต่ต้องมีขั้นตอนเพิ่มเติมที่เกี่ยวข้องกับคลัสเตอร์โดยเฉพาะ เช่น การตั้งค่าการเข้าถึงพื้นที่จัดเก็บข้อมูลร่วมระหว่างโหนดทั้งหมด ก่อนเริ่มคำสั่งทำซ้ำ
คำถามที่ 3: หากสแตนด์บายที่สร้างขึ้นซ้ำล้มเหลวในการตรวจสอบสุขภาพทันทีหลังจากการสร้าง ผมควรทำอย่างไร?
ตรวจสอบบันทึกการแจ้งเตือน/ดูข้อความแสดงข้อผิดพลาด จากนั้นตรวจสอบพารามิเตอร์การกำหนดค่าอีกครั้ง เช่น เส้นทางไฟล์/ชื่อบริการ/การเชื่อมต่อเครือข่าย จนกว่าปัญหาจะได้รับการแก้ไขอย่างสมบูรณ์
สรุป
การทำซ้ำฐานข้อมูลเป้าหมายสำหรับโหมดสแตนด์บายจากแหล่งที่มาที่กำลังทำงานอยู่ช่วยให้ธุรกิจสามารถรับมือกับเหตุขัดข้องได้อย่างมีประสิทธิภาพ พร้อมลดความเสี่ยงในการหยุดทำงานลงต่ำที่สุด ไม่ว่าคุณจะเลือกใช้วิธีการทำงานด้วย RMAN แบบแมนนวล หรือตั้งค่า Data Guard โดยอัตโนมัติ กระบวนการเหล่านี้จะมีความน่าเชื่อถือได้เมื่อเข้าใจและควบคุมได้อย่างชำนาญ Vinchin ช่วยให้การปกป้องและการย้ายฐานข้อมูลทำได้ง่ายยิ่งขึ้น ดาวน์โหลดทดลองใช้ฟรีได้แล้ววันนี้
