Esta página se ha traducido con Cloud Translation API.

Validar la implementación de Data Guard

Después de configurar el intermediario de Data Guard, debe verificar que se ha copiado el redo de la base de datos principal y se ha aplicado en la base de datos de reserva. El siguiente procedimiento se puede usar para comprobar el estado de Data Guard desde las bases de datos principal y de 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 espera

Validar la implementación de Data Guard

Inicia sesión en el primer servidor de Solución Bare Metal que aloja la base de datos principal y, a continuación, define la variable de entorno ORACLE_SID para poder conectarte a la base de datos principal:
```
source oraenv <<< "DBDG_SITE11"
```
Inicia SQL*Plus y, a continuación, determina el número de secuencia más reciente de 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;
```
La siguiente salida tiene un número de secuencia máximo de 40 para el hilo 1 y un número de secuencia máximo de 33 para el hilo 2:
```
   THREAD# Last Primary Seq Archived
---------- -------------------------
         1                        40
         2                        33
```
Registre los resultados para compararlos con la base de datos de reserva. Se espera que los números de secuencia de la base de datos de reserva coincidan con los de la base de datos principal.
Inicia sesión en el primer servidor de Solución Bare Metal que aloja la base de datos de reserva y, a continuación, define la variable de entorno ORACLE_SID para poder conectarte a la base de datos de reserva:
```
source oraenv <<< "DBDG_SITE21"
```

Inicia SQL*Plus y, a continuación, valida que el último número de secuencia recibido y aplicado a los registros de rehacer archivados coincida con el último número de secuencia de 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 ejecución de la consulta anterior en la base de datos de espera:

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

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

Comprueba que el estado del proceso de recuperación gestionado 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 gestionado llamado MRP0 con el estado APPLYING_LOG:
```
PROCESS   STATUS
--------- ------------
MRP0      APPLYING_LOG
```

Comprueba si hay algún retraso en el transporte o en la aplicación en la base de datos de espera:

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

En el siguiente resultado no se muestra ningún retraso en la base de datos de espera:

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

Si hay latencia, consulta la documentación para solucionar problemas de Data Guard de Oracle.

Cambio de base de datos mediante el broker de Data Guard

Un cambio de rol es una inversión de roles en la que la base de datos principal se convierte en una base de datos de reserva y viceversa. Durante el proceso de cambio, los clientes de la base de datos se desconectan de la base de datos principal. En función de 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. Para probar si tu sistema está preparado para la recuperación tras fallos, sigue estas instrucciones para cambiar de una base de datos a otra:

Inicia sesión en el servidor de Bare Metal Solution que aloja la base de datos principal.
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
```
Cuando se te pida una contraseña, introduce la contraseña de inicio de sesión remoto SYS de la base de datos.
Valida que la base de datos esté lista para un cambio.
```
VALIDATE DATABASE DBDG_SITE2;
```
Si el resultado es correcto, se indicará que la base de datos está lista para el cambio.
Si la acción se realiza correctamente, ejecuta el comando de cambio:
```
SWITCHOVER TO DBDG_SITE2;
```
Si el comando se ejecuta correctamente, recibirás un mensaje que indica que DBDG_SITE2 es la nueva base de datos principal de la configuración.
Ejecuta el siguiente comando para confirmar que se han intercambiado los roles de la base de datos:
```
SHOW CONFIGURATION;
```
Ejecuta el siguiente comando para volver a la configuración original:
```
SWITCHOVER TO DBDG_SITE1;
```

Conmutación por error de la base de datos mediante el broker de Data Guard

Una conmutación por error es una transición de rol en la que una de las bases de datos de reserva pasa a ser la principal debido a una interrupción completa del sitio. La rehacer no se enviará a la base de datos en espera hasta que se haya restaurado.

Realizar la conmutación por error

Inicia sesión en el primer servidor de Bare Metal Solution que aloja la base de datos de espera.
Conéctate a la interfaz de línea de comandos de Data Guard y, a continuación, conmuta por error la base de datos principal a la de reserva:
```
dgmgrl
```
```
CONNECT SYS@DBDG_SITE2
```
Cuando se te pida una contraseña, introduce la contraseña de inicio de sesión remoto SYS de la base de datos.
Inicializa la conmutación por error:
```
FAILOVER TO DBDG_SITE2
```
Ejecuta show configuration; para verificar que DBDG_SITE2 es ahora la base de datos principal y que DBDG_SITE1 debe restaurarse.

Restablecer la base de datos principal

Solo puedes restaurar la base de datos principal después de una conmutación por error si flashback database está habilitada. Para restaurar la base de datos principal que ha fallado, sigue estos pasos:

Inicia sesión en el primer servidor de Bare Metal Solution que aloja la base de datos principal.
Conéctate a la interfaz de línea de comandos de Data Guard, inicia sesión en las bases de datos primarias y, a continuación, restaura la base de datos que ha fallado:
```
dgmgrl
```
```
CONNECT SYS@DBDG_SITE2
```
Cuando se te pida una contraseña, introduce la contraseña de inicio de sesión remoto SYS de la base de datos.
Restablece la base de datos:
```
REINSTATE DATABASE DBDG_SITE1;
EXIT;
```

Pasos siguientes

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