Oracle Snapshot Standby ซึ่งเป็นคุณลักษณะหนึ่งของซอฟต์แวร์ Oracle's Data Guard ช่วยให้สามารถแปลงฐานข้อมูลสแตนด์บายทางกายภาพเป็น snapshot standby ได้ชั่วคราวเพื่อดำเนินการอ่านและเขียน ซึ่งเหมาะอย่างยิ่งสำหรับการทดสอบโดยไม่มีความเสี่ยง และสามารถเปลี่ยนกลับไปเป็นสแตนด์บายทางกายภาพได้อีกครั้ง โดยจะทิ้งการเปลี่ยนแปลงทั้งหมดและกลับมาดำเนินการใช้ข้อมูล redo ต่อ
Updated by ออฟโรด แซ่ฉั่ว on 2025/12/12
Data Guard ของ Oracle 11g ไม่เพียงมีคุณสมบัติที่โดดเด่นอย่างการสืบค้นข้อมูลแบบเรียลไทม์ผ่าน Active Data Guard เท่านั้น แต่ยังมีคุณสมบัติที่น่าสนใจอีกอย่างหนึ่งคือ ฟังก์ชัน Snapshot Standby Database ซึ่งทำให้ฐานข้อมูลสำรองสามารถอยู่ในโหมด "อ่าน-เขียน" ได้ โดยทำหน้าที่เป็นสภาพแวดล้อมสำหรับการทดสอบงานต่าง ๆ ที่อาจไม่สะดวกในการดำเนินการโดยตรงบนฐานข้อมูลหลักที่ใช้งานจริง เช่น การจำลองการปรับใช้งานออนไลน์และงานอื่น ๆ เมื่อดำเนินการต่าง ๆ เสร็จสิ้นในโหมดอ่าน-เขียนแล้ว จะสามารถเปลี่ยนบทบาทของฐานข้อมูลสำรองแบบสแนปชอตกลับไปเป็นฐานข้อมูลสำรองได้อย่างง่ายดาย และกลับมาซิงค์ข้อมูลกับฐานข้อมูลหลักต่อไป ขณะอยู่ในสถานะฐานข้อมูลสำรองแบบสแนปช็อต ระบบสามารถรับบันทึก (logs) จากฐานข้อมูลหลักได้ แต่การเปลี่ยนแปลงเหล่านั้นจะไม่สามารถนำไปประยุกต์ใช้กับฐานข้อมูลสำรองได้
หากฐานข้อมูลสำรองกำลังดำเนินการ Redo Apply อยู่ในขณะนี้ จะจำเป็นต้องยุติกระบวนการดังกล่าวก่อน
sys@ora11gdg> alter database recover managed standby database cancel; Database altered.
sys@ora11gdg> select database_role,open_mode from v$database; DATABASE_ROLE OPEN_MODE PHYSICAL STANDBY MOUNTED
ในขณะนี้ ฐานข้อมูลสำรองทำหน้าที่เป็นฐานข้อมูลสำรองทางกายภาพและทำงานในโหมด MOUNTED
เตือนความจำ: การเปิดใช้งานฟังก์ชันฐานข้อมูลสำรองแบบสแนปชอตไม่จำเป็นต้องเปิดใช้งานคุณสมบัติแฟลชแบ็คฐานข้อมูลบนฐานข้อมูลหลักและฐานข้อมูลสำรองทั้งสอง ซึ่งเป็นอิสระจากสถานะการเปิดใช้งานคุณสมบัติแฟลชแบ็คฐานข้อมูล
sys@ora11gdg> show parameter db_recovery_file_dest NAME TYPE VALUE db_recovery_file_dest string /u01/app/oracle/flash_recovery_area db_recovery_file_dest_size big integer 3852M
ยืนยันว่าคุณลักษณะการถอยกลับ (flashback) ไม่ได้เปิดใช้งานบนฐานข้อมูลหลัก
sys@ora11g> select FLASHBACK_ON from v$database; FLASHBACK_ON NO
ยืนยันว่าคุณลักษณะการย้อนกลับไม่ได้ถูกเปิดใช้งานบนฐานข้อมูลสำรอง
sys@ora11gdg> select FLASHBACK_ON from v$database; FLASHBACK_ON NO
sys@ora11gdg> alter database convert to snapshot standby; Database altered. sys@ora11gdg> select database_role,open_mode from v$database; DATABASE_ROLE OPEN_MODE SNAPSHOT STANDBY MOUNTED
sys@ora11gdg> alter database open; Database altered. sys@ora11gdg> select database_role,open_mode from v$database; DATABASE_ROLE OPEN_MODE SNAPSHOT STANDBY READ WRITE
ฐานข้อมูลอ่าน-เขียนที่ทั้งใหม่และทันสมัยปรากฏขึ้นต่อหน้าเรา
บันทึกการแจ้งเตือนของฐานข้อมูลหลักสำหรับ Oracle 11g:
Mon Mar 19 18:46:28 2012 LNS: Attempting destination LOG_ARCHIVE_DEST_2 network reconnect (3135) LNS: Destination LOG_ARCHIVE_DEST_2 network reconnect abandoned Errors in file /u01/app/oracle/diag/rdbms/ora11g/ora11g/trace/ora11g_nsa2_27302.trc: ORA-03135: connection lost contact Error 3135 for archive log file 2 to 'ora11gdg' Errors in file /u01/app/oracle/diag/rdbms/ora11g/ora11g/trace/ora11g_nsa2_27302.trc: ORA-03135: connection lost contact LNS: Failed to archive log 2 thread 1 sequence 50 (3135) Errors in file /u01/app/oracle/diag/rdbms/ora11g/ora11g/trace/ora11g_nsa2_27302.trc: ORA-03135: connection lost contact
บันทึกการแจ้งเตือนฐานข้อมูลสำรองสำหรับ Oracle 11g:
Mon Mar 19 18:46:26 2012 alter database convert to snapshot standby Starting background process RVWR Mon Mar 19 18:46:26 2012 RVWR started with pid=26, OS id=8824 Allocated 3981204 bytes in shared pool for flashback generation buffer Created guaranteed restore point SNAPSHOT_STANDBY_REQUIRED_03/19/2012 18:46:26 krsv_proc_kill: Killing 3 processes (all RFS) Begin: Standby Redo Logfile archival End: Standby Redo Logfile archival RESETLOGS after complete recovery through change 1472476 Resetting resetlogs activation ID 4174194338 (0xf8cd26a2) Online log /u01/app/oracle/oradata/ora11gdg/redo01.log: Thread 1 Group 1 was previously cleared Online log /u01/app/oracle/oradata/ora11gdg/redo02.log: Thread 1 Group 2 was previously cleared Online log /u01/app/oracle/oradata/ora11gdg/redo03.log: Thread 1 Group 3 was previously cleared Standby became primary SCN: 1472474 Mon Mar 19 18:46:29 2012 Setting recovery target incarnation to 5 CONVERT TO SNAPSHOT STANDBY: Complete - Database mounted as snapshot standby Completed: alter database convert to snapshot standby
ข้อความสำคัญระบุว่า "Created guaranteed restore point SNAPSHOT_STANDBY_REQUIRED_03/19/2012 18:46:26" ซึ่งบ่งชี้ถึงช่วงเวลาที่เราเปลี่ยนเป็นภาพถ่าย เพื่ออำนวยความสะดวกในการย้อนกลับในขั้นตอนถัดไป
แม้ว่าฐานข้อมูลหลักจะสลับบันทึก แต่ฐานข้อมูลสำรองยังคงดำเนินการรับบันทึกต่อไป แม้จะไม่นำบันทึกเหล่านั้นมาใช้ก็ตาม
1) เปลี่ยนลอจ์ในฐานข้อมูลหลัก
sys@ora11g> alter system switch logfile; System altered.
2) เนื้อหาบันทึกการแจ้งเตือนที่ถูกบันทึกโดยฐานข้อมูลหลัก
บันทึกการแจ้งเตือนฐานข้อมูลหลักสำหรับ Oracle 11g:
Mon Mar 19 18:52:00 2012 Thread 1 cannot allocate new log, sequence 52 Private strand flush not complete Current log# 3 seq# 51 mem# 0: /u01/app/oracle/oradata/ora11g/redo03.log Mon Mar 19 18:52:00 2012 ARC3: Standby redo logfile selected for thread 1 sequence 50 for destination LOG_ARCHIVE_DEST_2 Thread 1 advanced to log sequence 52 (LGWR switch) Current log# 1 seq# 52 mem# 0: /u01/app/oracle/oradata/ora11g/redo01.log Mon Mar 19 18:52:03 2012 Archived Log entry 91 added for thread 1 sequence 51 ID 0xf8cd26a2 dest 1: Mon Mar 19 18:52:03 2012 LNS: Standby redo logfile selected for thread 1 sequence 51 for destination LOG_ARCHIVE_DEST_2 LNS: Standby redo logfile selected for thread 1 sequence 52 for destination LOG_ARCHIVE_DEST_2
บันทึกการแจ้งเตือนฐานข้อมูลสำรองสำหรับ Oracle 11g:
Mon Mar 19 18:52:00 2012 RFS[5]: Assigned to RFS process 9174 RFS[5]: Identified database type as 'snapshot standby': Client is ARCH pid 27296 Mon Mar 19 18:52:00 2012 RFS[6]: Assigned to RFS process 9176 RFS[6]: Identified database type as 'snapshot standby': Client is ARCH pid 27300 RFS[6]: Selected log 4 for thread 1 sequence 50 dbid -120744030 branch 778023141 Mon Mar 19 18:52:00 2012 Archived Log entry 47 added for thread 1 sequence 50 ID 0xf8cd26a2 dest 1: Mon Mar 19 18:52:03 2012 RFS[7]: Assigned to RFS process 9180 RFS[7]: Identified database type as 'snapshot standby': Client is LGWR ASYNC pid 27302 RFS[7]: Selected log 4 for thread 1 sequence 51 dbid -120744030 branch 778023141 Mon Mar 19 18:52:04 2012 Archived Log entry 48 added for thread 1 sequence 51 ID 0xf8cd26a2 dest 1: RFS[7]: Selected log 4 for thread 1 sequence 52 dbid -120744030 branch 778023141
3) การตรวจสอบเนื้อหาของไฟล์บันทึกในไดเรกทอรีเก็บถาวรของฐานข้อมูลหลักและฐานข้อมูลสำรอง
(1) แฟ้มบันทึกประวัติของฐานข้อมูลหลัก:
ora11g@secdb /home/oracle/arch/ora11g$ ls -ltr total 879M ...omitted... -rw-r----- 1 oracle oinstall 1.1M Mar 19 18:51 1_50_778023141.arc -rw-r----- 1 oracle oinstall 363K Mar 19 18:52 1_51_778023141.arc
(2) ไฟล์บันทึกการเก็บถาวรของฐานข้อมูลสำรอง:
ora11g@secdb /home/oracle/arch/ora11gdg$ ls -ltr total 847M ...omitted... -rw-r----- 1 oracle oinstall 1.1M Mar 19 18:52 1_50_778023141.arc -rw-r----- 1 oracle oinstall 363K Mar 19 18:52 1_51_778023141.arc
ตามที่สังเกต ฐานข้อมูลสำรองได้รับไฟล์บันทึกที่ส่งมาจากฐานข้อมูลหลักเรียบร้อยแล้ว
sys@ora11gdg> create user ocmu identified by ocmu;
User created.
secooler@ora11gdg> grant dba to ocmu;
Grant succeeded.
secooler@ora11gdg> conn ocmu/ocmu
Connected.
ocmu@ora11gdg> create table t (x varchar2(8));
Table created.
ocmu@ora11gdg> insert into t values ('Secooler');
1 row created.
ocmu@ora11gdg> commit;
Commit complete.
ocmu@ora11gdg> select * from t;
X
Secoolerในขณะนี้ ฐานข้อมูลสำรองอยู่ในสถานะที่สามารถปรับเปลี่ยนได้ ซึ่งสอดคล้องกับโหมด "READ WRITE" ที่ต้องการ
สิ่งสำคัญคือต้องทราบว่าการใช้งานฟังก์ชันฐานข้อมูลแบบ Snapshot Standby นั้นขึ้นอยู่กับหลักการของข้อมูลแฟลชแบ็คอย่างพื้นฐาน ดังนั้นควรหลีกเลี่ยงการดำเนินการใด ๆ ที่อาจทำให้ไม่สามารถแฟลชแบ็คฐานข้อมูลได้ มิฉะนั้น ฐานข้อมูลแบบ snapshot standby จะไม่สามารถกลับสู่สถานะการกู้คืนแบบสแตนด์บายก่อนหน้าได้
1) รีสตาร์ทฐานข้อมูลสำรองใหม่ในสถานะ MOUNTED
ocmu@ora11gdg> conn / as sysdba Connected. sys@ora11gdg> shutdown immediate Database closed. Database dismounted. ORACLE instance shut down. sys@ora11gdg> startup mount ORACLE instance started. Total System Global Area 313860096 bytes Fixed Size 1336232 bytes Variable Size 268438616 bytes Database Buffers 37748736 bytes Redo Buffers 6336512 bytes Database mounted. sys@ora11gdg> select database_role,open_mode from v$database; DATABASE_ROLE OPEN_MODE SNAPSHOT STANDBY MOUNTED
2) ดำเนินการคำสั่งเพื่อกู้คืนอัตลักษณ์เดิมของฐานข้อมูลสำรองทางกายภาพ
sys@ora11gdg> alter database convert to physical standby; Database altered.
3) บันทึกการแจ้งเตือนของฐานข้อมูลสำรองได้จดบันทึกกระบวนการเปลี่ยนผ่านนี้อย่างละเอียดถี่ถ้วน
Mon Mar 19 19:30:24 2012 alter database convert to physical standby ALTER DATABASE CONVERT TO PHYSICAL STANDBY (ora11gdg) Flashback Restore Start Flashback Restore Complete Stopping background process RVWR Deleted Oracle managed file /u01/app/oracle/flash_recovery_area/ORA11GDG/flashback/o1_mf_7pg3n2jc_.flb Deleted Oracle managed file /u01/app/oracle/flash_recovery_area/ORA11GDG/flashback/o1_mf_7pg52yst_.flb Guaranteed restore point dropped Clearing standby activation ID 4174523254 (0xf8d22b76) The primary database controlfile was created using the 'MAXLOGFILES 30' clause. There is space for up to 27 standby redo logfiles Use the following SQL commands on the standby database to create standby redo logfiles that match the primary database: ALTER DATABASE ADD STANDBY LOGFILE 'srl1.f' SIZE 52428800; ALTER DATABASE ADD STANDBY LOGFILE 'srl2.f' SIZE 52428800; ALTER DATABASE ADD STANDBY LOGFILE 'srl3.f' SIZE 52428800; ALTER DATABASE ADD STANDBY LOGFILE 'srl4.f' SIZE 52428800; Completed: alter database convert to physical standby
จากบันทึกการแจ้งเตือน สามารถสรุปได้ว่า วิธีการกู้คืนใช้คุณลักษณะ Flashback Database สิ่งนี้แสดงให้เห็นว่าแม้ฐานข้อมูลสำรองจะไม่ได้ทำงานในโหมด flashback database การเปลี่ยนบทบาทของฐานข้อมูลสำรองก็ยังสามารถดำเนินการได้โดยใช้ฟังก์ชันการทำงานของ Flashback Database
4) รีสตาร์ทฐานข้อมูลสำรองใหม่ในโหมดการกู้คืนล็อกอัตโนมัติ
(1) ณ จุดนี้ ฐานข้อมูลอยู่ในสถานะ NOMOUNTED และจำเป็นต้องเริ่มต้นใหม่
โปรดทราบว่าต้องมีการรีสตาร์ทฐานข้อมูล แทนการใช้คำสั่ง ALTER มิฉะนั้นจะพบข้อความแสดงข้อผิดพลาดดังต่อไปนี้:
sys@ora11gdg> alter database mount; alter database mount l ERROR at line 1: ORA-00750: database has been previously mounted and dismounted sys@ora11gdg> shutdown immediate; ORA-01507: database not mounted ORACLE instance shut down. sys@ora11gdg> startup mount; ORACLE instance started. Total System Global Area 313860096 bytes Fixed Size 1336232 bytes Variable Size 268438616 bytes Database Buffers 37748736 bytes Redo Buffers 6336512 bytes Database mounted. sys@ora11gdg> alter database recover managed standby database disconnect; Database altered.
(2) ด้วยการตรวจสอบบันทึกการแจ้งเตือนของฐานข้อมูลสำรอง สามารถสังเกตกระบวนการกู้คืนได้อย่างชัดเจน
Mon Mar 19 19:43:48 2012 Managed Standby Recovery not using Real Time Apply Parallel Media Recovery started with 4 slaves Waiting for all non-current ORLs to be archived... All non-current ORLs have been archived. Clearing online redo logfile 1 /u01/app/oracle/oradata/ora11gdg/redo01.log Clearing online log 1 of thread 1 sequence number 1 Completed: alter database recover managed standby database disconnect Clearing online redo logfile 1 complete Clearing online redo logfile 2 /u01/app/oracle/oradata/ora11gdg/redo02.log Clearing online log 2 of thread 1 sequence number 2 Clearing online redo logfile 2 complete Media Recovery Log /home/oracle/arch/ora11gdg/1_49_778023141.arc Media Recovery Log /home/oracle/arch/ora11gdg/1_50_778023141.arc Media Recovery Log /home/oracle/arch/ora11gdg/1_51_778023141.arc Media Recovery Log /home/oracle/arch/ora11gdg/1_52_778023141.arc Media Recovery Log /home/oracle/arch/ora11gdg/1_53_778023141.arc Media Recovery Log /home/oracle/arch/ora11gdg/1_54_778023141.arc Media Recovery Waiting for thread 1 sequence 55
(3) ตรวจสอบสถานะการใช้งานบันทึกโดยการตรวจสอบมุมมองประสิทธิภาพแบบไดนามิก V$ARCHIVED_LOG
sys@ora11gdg> select sequence#, first_time, next_time, applied from v$archived_log order by sequence#; SEQUENCE# FIRST_TIME NEXT_TIME APPLIED ...omitted... 49 20120319 18:32:32 20120319 18:38:03 YES 50 20120319 18:38:03 20120319 18:51:00 YES 51 20120319 18:51:00 20120319 18:52:03 YES 52 20120319 18:52:03 20120319 19:09:57 YES 53 20120319 19:09:57 20120319 19:10:15 YES 54 20120319 19:10:15 20120319 19:10:25 YES 52 rows selected.
sys@ora11gdg> alter database recover managed standby database cancel; Database altered. sys@ora11gdg> alter database open read only; Database altered. sys@ora11gdg> select database_role,open_mode from v$database; DATABASE_ROLE OPEN_MODE PHYSICAL STANDBY READ ONLY sys@ora11gdg> select username from dba_users where username = 'OCMU'; no rows selected
ผลสรุปได้รับการยืนยันแล้ว เนื่องจากผู้ใช้ทดสอบ "OCMU" ที่สร้างไว้ก่อนหน้านี้ไม่มีอยู่จริง
Oracle Snapshot Standby มีประโยชน์อย่างยิ่งสำหรับการทดสอบ อย่างไรก็ตาม เพื่อเพิ่มการป้องกันสภาพแวดล้อมฐานข้อมูลของคุณ ขอแนะนำให้สำรองข้อมูลฐานข้อมูล Oracle ด้วยโซลูชันสำรองข้อมูลและการกู้คืนระบบภัยพิบัติระดับมืออาชีพ
Vinchin Backup & Recovery มีฟังก์ชันการทำงานที่ทรงพลังเพื่อปกป้องฐานข้อมูลของคุณทั้งในเครื่องเสมือนและเซิร์ฟเวอร์จริง ซึ่งค่อนข้างอัตโนมัติ มีความยืดหยุ่น และมีประสิทธิภาพ ยังให้การป้องกันฐานข้อมูลหลายประเภท ได้แก่ Oracle DB, MySQL, SQL Server, Postgres Pro และ MariaDB รองรับการบีบอัดฐานข้อมูล การจัดการงานแบบรวมศูนย์ กลยุทธ์การสำรองข้อมูลอัจฉริยะ การสำรองข้อมูลขณะใช้งาน (hot database backup) และการรองรับขั้นสูงสำหรับ SQL Server/Oracle นอกจากนี้ยังรองรับฟีเจอร์การป้องกันแรนซัมแวร์ที่ทรงพลัง และการโยกย้าย V2V ข้ามแพลตฟอร์มเสมือนมากกว่า 10 แพลตฟอร์ม
Vinchin Backup & Recovery ได้รับการคัดเลือกจากบริษัทหลายพันแห่ง และคุณก็สามารถเริ่มใช้งานระบบที่ทรงพลังนี้ด้วย ทดลองใช้งานฟีเจอร์ครบถ้วนฟรี 60 วัน นอกจากนี้ ติดต่อ Vinchin โดยตรง และแจ้งความต้องการของคุณ จากนั้นคุณจะได้รับโซลูชันที่สอดคล้องกับสภาพแวดล้อม IT ของคุณ
คุณสมบัติที่โดดเด่นของฐานข้อมูล snapshot standby ช่วยให้ฐานข้อมูลสำรองสามารถกลายเป็นฐานข้อมูลอิสระที่อ่านและเขียนได้ชั่วคราว สิ่งนี้ทำให้ขยายความเป็นไปได้ในการใช้งานฐานข้อมูลสำรองอย่างมาก โดยการใช้ความสามารถพิเศษของฐานข้อมูลสำรองนี้ คุณสามารถทดสอบและจำลองปัญหาที่อาจมีความ "เสี่ยง" ในการจำลองและทำซ้ำในสภาพแวดล้อมการผลิตได้อย่างปลอดภัย เมื่อการทดสอบเสร็จ คุณสามารถกู้คืนสถานะเป็นฐานข้อมูลสแตนด์บายทางกายภาพและดำเนินการกู้คืนจากบันทึกต่อไปได้
แชร์บน:
