Oracle Snapshot Standby, una característica del software Oracle Data Guard, permite la conversión temporal de una base de datos standby física en una snapshot standby para operaciones de lectura y escritura. Es ideal para pruebas sin riesgos, ya que se puede revertir a una standby física, descartando todos los cambios y reanudando la aplicación de datos redo.
Updated by Alejandro on 2025/05/15
La función Data Guard de Oracle 11g no solo nos brinda la característica notable de consultar en tiempo real a través del Active Data Guard, sino también un beneficio adicional conocido como la funcionalidad de base de datos de Snapshot Standby. Esta funcionalidad permite poner la base de datos secundaria en modo "lectura-escritura", sirviendo como un entorno para pruebas que podrían ser incómodas de realizar directamente en la base de datos principal de producción, como simular implementaciones en línea y otras tareas. Una vez que se completan las tareas en el estado de lectura-escritura, es sencillo volver a cambiar el rol de la base de datos de Snapshot Standby a su rol de base de datos secundaria, reanudando la sincronización con la base de datos principal. Mientras esté en el estado de base de datos de Snapshot Standby, puede recibir los registros de la base de datos principal, pero los cambios no se pueden aplicar a la base de datos secundaria.
Si la base de datos standby está actualmente realizando el procedimiento Redo Apply, es necesario terminarlo primero.
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
En este momento, la base de datos de espera asume el rol de una base de datos física de espera y opera en el modo MOUNTED.
Recordatorio amistoso: Habilitar la funcionalidad de base de datos de Snapshot Standby no requiere habilitar la función de Flashback Database en las bases de datos principal y de standby. Es independiente de si está habilitada la función de flashback database.
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
Confirma que la función de flash back no esté habilitada en la base de datos principal.
sys@ora11g> select FLASHBACK_ON from v$database; FLASHBACK_ON NO
Confirma que la función de flashback no esté habilitada en la base de datos de standby.
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
Una completamente nueva base de datos de lectura-escritura se presenta ante nosotros.
Registro de alertas de la base de datos principal para 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
Registro de alerta de la base de datos en espera para 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
La línea crucial de información indica: "Punto de restauración garantizado creado SNAPSHOT_STANDBY_REQUIRED_03/19/2012 18:46:26." Esto marca el momento en que nos convertimos en una instantánea, facilitando la posterior reversión.
Incluso cuando la base de datos principal cambia los registros, la base de datos en espera sigue recibiendo los registros, aunque sin aplicarlos.
1) Cambio de registro en la base de datos principal.
sys@ora11g> alter system switch logfile; System altered.
2) El contenido del registro de alertas registrado por la base de datos principal
Registro de alertas de la base de datos principal para 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
Registro de alertas de la base de datos en espera para 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) Examinar el contenido de los archivos de registro en los directorios de archivo de las bases de datos principal y de standby
(1) Archivos de registro de la base de datos principal:
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) Archivos de registro de la base de datos de standby:
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
Como se observa, la base de datos de standby ha recibido con éxito los archivos de registro enviados desde la base de datos principal.
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
SecoolerEn este momento, la base de datos de espera se encuentra en un estado modificable y ajustable, lo que corresponde al modo deseado “LECTURA ESCRITURA”.
Es crucial tener en cuenta que la implementación de la funcionalidad de la base de datos de Snapshot Standby se basa fundamentalmente en el principio de datos de flashback. Por lo tanto, cualquier acción que pueda obstaculizar la capacidad de realizar un flashback de la base de datos debe evitarse aquí. De lo contrario, la base de datos de snapshot standby no podrá volver a su estado anterior de recuperación standby.
1) Reinicia la base de datos de espera al estado 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) Ejecute un comando para restaurar la identidad original de la base de datos standby física.
sys@ora11gdg> alter database convert to physical standby; Database altered.
3) El registro de alertas de la base de datos de standby documenta meticulosamente este proceso de transición.
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
Del registro de alertas se puede inferir que el método de recuperación utilizó la característica Flashback Database. Esto implica que, incluso si la base de datos de standby no estaba ejecutándose en modo de base de datos con flashback, la transición de roles de la base de datos de standby aún se puede realizar utilizando la funcionalidad de Flashback Database.
4) Reinicie la base de datos de espera en el modo de registro de recuperación automática.
(1) En este punto, la base de datos se encuentra en el estado NOMOUNTED y necesita ser reiniciada.
Tenga en cuenta que se requiere un reinicio de la base de datos en lugar de usar el comando ALTER, de lo contrario se encontrará con el siguiente mensaje de error:
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) Al examinar el registro de alertas de la base de datos de standby, se puede observar el proceso de recuperación de manera clara.
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) Supervise el estado de la aplicación de registros inspeccionando la vista de rendimiento dinámico 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
La conclusión ha sido confirmada, ya que el usuario de prueba "OCMU" que se creó anteriormente no existe.
Oracle Snapshot Standby es muy útil para fines de prueba. Sin embargo, para proteger aún más su entorno de base de datos, se recomienda realizar una copia de seguridad de su base de datos Oracle con una solución profesional de copia de seguridad y recuperación ante desastres.
Vinchin Backup & Recovery ofrece una potente funcionalidad para proteger tus bases de datos tanto en máquinas virtuales como en servidores físicos, siendo bastante automático, flexible y eficiente. Proporciona protección multi-tipo de bases de datos de Oracle DB, MySQL, SQL Server, Postgres Pro y MariaDB, con soporte para compresión de bases de datos, gestión centralizada de trabajos, estrategias inteligentes de respaldo, respaldo de bases de datos en caliente y soporte avanzado para SQL Server/Oracle. Además, también admite una potente función de protección contra ransomware y migración V2V entre más de 10 plataformas virtuales.
Vinchin Backup & Recovery ha sido seleccionado por miles de empresas y tú también puedes comenzar a usar este poderoso sistema con una prueba completa de 60 días¡Sin límites! Además, contáctenos y comparte tus necesidades, y recibirás una solución adaptada a tu entorno de TI.
La característica notable de la “base de datos de instantáneas en espera” permite que la base de datos en espera se convierta temporalmente en una base de datos independiente de lectura y escritura. Esto amplía enormemente las posibilidades de aplicación de la base de datos en espera. Al aprovechar esta funcionalidad especial de la base de datos en espera, puedes probar y reproducir de manera segura problemas que podrían ser "arriesgados" de simular y reproducir en el entorno de producción. Una vez que se completa la prueba, puedes restaurar su identidad como base de datos física en espera y continuar con la recuperación de registros.
Compartir en:
