Valida la implementación de Data Guard

Después de configurar el agente de Data Guard, debes verificar que el rehacer se haya copiado de la base de datos principal y aplicado en la base de datos en espera. El siguiente procedimiento se puede usar para verificar el estado de Data Guard desde las bases de datos principal y en espera.

En esta guía, se usan los siguientes ejemplos:

Nombre único de la base de datos	Nombres de host del servidor	Nombres de instancias de RAC	Rol
DBDG_SITE1	site1db1, site1db2	DBDG_SITE11, DBDG_SITE12	Principal
DBDG_SITE2	site2db1, site2db2	DBDG_SITE21, DBDG_SITE22	En suspensión

Valida la implementación de Data Guard

1. Accede al primer servidor de la solución Bare Metal que aloja la base de datos principal y, luego, configura la variable de entorno ORACLE_SID para que puedas conectarte a la base de datos principal:

   source oraenv <<< "DBDG_SITE11"
   

2. Inicia SQL*Plus y, luego, determina el número de secuencia más reciente para los registros de rehacer archivados:

   sqlplus / as sysdba
   

   SELECT THREAD#, max(SEQUENCE#) "Last Primary Seq Archived"
   FROM V$ARCHIVED_LOG VAL, V$DATABASE VDB WHERE VAL.RESETLOGS_CHANGE# =
   VDB.RESETLOGS_CHANGE# GROUP BY THREAD# ORDER BY 1;
   

   El siguiente resultado tiene un número de secuencia máximo de 40 para el subproceso 1 y un número de secuencia máximo de 33 para el subproceso 2:

      THREAD# Last Primary Seq Archived
   ---------- -------------------------
            1                        40
            2                        33
   

   Registra los resultados para compararlos con la base de datos en espera. Se espera que los números de secuencia en la base de datos en espera coincidan con los de la base de datos principal.

3. Accede al primer servidor de la solución Bare Metal que aloja la base de datos en espera y, luego, configura la variable de entorno ORACLE_SID para que puedas conectarte a la base de datos en espera:

   source oraenv <<< "DBDG_SITE21"
   

4. Inicia SQL*Plus y, luego, verifica que el último número de secuencia recibido y aplicado a los registros de rehacer archivados coincida con el último número de secuencia en la base de datos principal:

   sqlplus / as sysdba
   

   SELECT THREAD#, max(SEQUENCE#) "Last Standby Seq Received"
   FROM V$ARCHIVED_LOG VAL, V$DATABASE VDB WHERE VAL.RESETLOGS_CHANGE# =
   VDB.RESETLOGS_CHANGE# GROUP BY THREAD# ORDER BY 1;
   

   SELECT THREAD#, max(SEQUENCE#) "Last Standby Seq Applied"
   FROM V$ARCHIVED_LOG VAL, V$DATABASE VDB WHERE VAL.RESETLOGS_CHANGE# =
   VDB.RESETLOGS_CHANGE# AND VAL.APPLIED IN ('YES','IN-MEMORY') GROUP BY
   THREAD# ORDER BY 1;
   

   El siguiente resultado tiene números de secuencia que coinciden con la consulta anterior que se ejecutó en la base de datos en espera:

      THREAD# Last Standby Seq Received
   ---------- -------------------------
            1                        40
            2                        33
   

      THREAD# Last Standby Seq Applied
   ---------- ------------------------
            1                       40
            2                       33
   

5. Comprueba que el estado del proceso de recuperación administrado sea APPLYING_LOG:

   SELECT PROCESS, STATUS FROM V$MANAGED_STANDBY WHERE PROCESS LIKE '%MRP%';
   

   En el siguiente ejemplo, se muestra un proceso de recuperación administrado único llamado MRP0 con el estado de APPLYING_LOG:

   PROCESS   STATUS
   --------- ------------
   MRP0      APPLYING_LOG
   

6. Verifica cualquier transporte o aplica retraso en la base de datos en espera:

   COLUMN NAME FORMAT a20
   COLUMN VALUE FORMAT a30
   SELECT NAME, VALUE FROM V$DATAGUARD_STATS WHERE NAME LIKE '%lag%';
   

   El siguiente resultado no muestra ningún retraso en la base de datos en espera:

   NAME                 VALUE
   -------------------- ------------------------------
   transport lag        +00 00:00:00
   apply lag            +00 00:00:00
   

   Si hay retrasos, consulta la documentación de solución de problemas de Data Guard de Oracle.

Cambio de base de datos mediante el agente de Data Guard

Un cambio es una reversión de roles en la que la base de datos principal se convierte en una base de datos en espera, y viceversa. Durante el proceso de cambio, los clientes de la base de datos se desconectan de la base de datos principal. Según cómo se conecte tu aplicación a la base de datos, un cambio puede interrumpir el tráfico de la aplicación. Oracle ofrece opciones para mantener la continuidad de las aplicaciones durante las transiciones de roles. Puedes probar la preparación de recuperación ante desastres mediante un cambio de base de datos con las siguientes instrucciones:

1. Accede al servidor de la solución Bare Metal que aloja la base de datos principal.

2. Inicia la interfaz de línea de comandos de Data Guard y conéctate a la base de datos en espera:

   dgmgrl
   

   CONNECT SYS@DBDG_SITE2
   

3. Cuando se te solicite una contraseña, ingresa tu contraseña de acceso remoto de SYS para la base de datos.

4. Verifica que la base de datos esté lista para el cambio.

   VALIDATE DATABASE DBDG_SITE2;
   

   Un resultado correcto informará que la base de datos está lista para el cambio.

5. Si se realiza de forma correcta, ejecuta el comando de cambio:

   SWITCHOVER TO DBDG_SITE2;
   

   Si el comando se ejecuta de forma correcta, recibirás un mensaje que indica que DBDG_SITE2 es la nueva base de datos principal en la configuración.

6. Ejecuta el siguiente comando para confirmar que se intercambiaron los roles de las bases de datos:

   SHOW CONFIGURATION;
   

7. Ejecuta el siguiente comando para volver a la configuración original:

   SWITCHOVER TO DBDG_SITE1;
   

Nota: Si ejecutas el comando de cambio mientras estás conectado a la base de datos principal, es posible que la conexión se descarte. Esto se debe a que la base de datos principal se reinicia durante el proceso de cambio.

Conmutación por error de la base de datos con el agente de Data Guard

Una conmutación por error es una transición de roles en la que una de las bases de datos en espera pasa al rol principal debido a una interrupción completa del sitio. El rehacer no se enviará a la base de datos en espera hasta que se restablezca la base de datos en espera.

Advertencia: Por lo general, una conmutación por error implica la pérdida de datos.

Realiza la conmutación por error

1. Accede al primer servidor de la solución Bare Metal que aloja la base de datos en espera.

2. Conéctate a la interfaz de línea de comandos de Data Guard y, luego, conmuta por error la principal a la base de datos en espera:

   dgmgrl
   

   CONNECT SYS@DBDG_SITE2
   

3. Cuando se te solicite una contraseña, ingresa tu contraseña de acceso remoto de SYS para la base de datos.

4. Inicia la conmutación por error:

   FAILOVER TO DBDG_SITE2
   

   Ejecuta show configuration; para verificar que DBDG_SITE2 ahora sea la base de datos principal y que DBDG_SITE1 se debe restablecer.

Restablece la base de datos principal

Solo puedes restablecer la base de datos principal después de una conmutación por error si se habilita flashback database. Para restablecer la base de datos principal con errores, sigue estos pasos:

1. Accede al primer servidor de la solución Bare Metal que aloja la base de datos principal.

2. Conéctate a la interfaz de línea de comandos de Data Guard, accede a las bases de datos principales y, luego, restablece la base de datos con errores:

   dgmgrl
   

   CONNECT SYS@DBDG_SITE2
   

   Cuando se te solicite una contraseña, ingresa tu contraseña de acceso remoto de SYS para la base de datos.

3. Restablece la base de datos:

   REINSTATE DATABASE DBDG_SITE1;
   EXIT;
   

Próximos pasos

A continuación, configura un observador de Data Guard en Compute Engine.