Verifique la configuración

Cuando se complete la configuración de DR, valide inmediatamente que la configuración sea correcta mediante un switchover completo o la apertura del sitio secundario para la validación. Abrir el sitio secundario para la validación no afectará el sistema que se ejecuta en el principal.

Abrir secundario para validación

Puede validar la ubicación en espera sin realizar un switchover completo convirtiendo la base de datos en espera en una base de datos de instantánea en espera. Esto permite iniciar los servidores SOA secundarios en el sitio en espera y verificar el sistema secundario. Cualquier cambio realizado en la base de datos de ubicación en espera mientras está en modo de instantánea en espera se desechará una vez que se vuelva a convertir en física en espera. Los datos principales no se ven afectados por las validaciones de sitios secundarios.

Nota:

Esta operación se debe realizar con precaución: si hay mensajes pendientes o compuestos en la base de datos cuando se convierte en instantánea, los servidores SOA de la ubicación en espera los procesarán cuando se inicien. Compruebe que no hay acciones pendientes en la base de datos primaria al convertir a la instantánea en espera. De lo contrario, elimine los registros de las tablas SOA de tiempo de ejecución en la base de datos en espera después de convertirlas en base de datos de instantánea en espera y antes de iniciar los servidores SOA de la ubicación secundaria. Consulte Eliminación de Registros de las Tablas de Tiempo de Ejecución sin Borrar las Tablas para conocer los pasos para validar la ubicación en espera sin realizar un switchover.

Como usuario oracle, utilice Oracle Data Guard Broker en el host de base de datos principal y convierta el secundario en una instantánea en espera.
```
[oracle@dbhost1~]$ dgmgrl sys/your_sys_password@primary_db_unqname
DGMGRL> convert database secondary_db_unqname to snapshot standby
```
Utilice el comando show configuration para verificar que la conversión se ha realizado correctamente.
Verifique que no haya acciones pendientes en el entorno secundario.
Si hay acciones pendientes (transacciones, mensajes) en la base de datos primaria cuando la base de datos en espera se convierte en instantánea, los servidores SOA secundarios intentarán procesarlas cuando start.You pueda utilizar el script de truncamiento de SOA para eliminar los registros de las tablas de tiempo de ejecución de SOA en la base de datos secundaria para limpiar los datos de tiempo de ejecución antes de iniciar los servidores secundarios. Ejecute esta acción con precaución; no trunque las tablas en la base de datos primaria. Consulte Eliminación de registros de las tablas de tiempo de ejecución sin borrar las tablas.
Si aún no están activos, inicie los sistemas Oracle HTTP Server en el sitio secundario.
Inicie el servidor de administración en el sitio secundario.
Inicie los servidores gestionados secundarios en el sitio secundario.
Utilice la consola o los scripts WebLogic para iniciar los servidores gestionados secundarios.
Valide el sitio secundario.

Como no se trata de un switchover y la ubicación principal aún está activa, el nombre de front-end virtual se resolverá en la dirección IP del equilibrador de carga de la ubicación principal, por lo que, por defecto, cualquier acceso al explorador se redirigirá a la ubicación principal activa.

Para acceder directamente a los servicios SOA del sitio secundario, debe actualizar el archivo /etc/hosts en un cliente controlado (por ejemplo, un equipo portátil), definir el nombre de front-end virtual para que se resuelva en la dirección IP del equilibrador de carga front-end del sitio secundario y ejecutar cualquier validación desde este cliente.

Nota:
Verifique que el cliente utilizado para las validaciones no acceda al sistema a través de un proxy HTTP, porque el proxy HTTP puede seguir resolviendo el nombre de front-end virtual con la dirección IP del equilibrador de carga del sitio principal, independientemente del nombre que se encuentre en /etc/hosts del cliente.

Es posible que los clientes que no son Linux requieran un restablecimiento de su caché DNS local antes de que un explorador resuelva la dirección IP mediante la entrada de archivo de host personalizado.

Una vez que se haya validado el sitio secundario, vaya al paso siguiente para revertirlo al rol en espera.

Nota:
Puede tardar tiempo en validar el sitio secundario.
Pare los servidores gestionados y los servidores de administración en el sitio secundario.
Utilice la consola WebLogic secundaria para cerrar los servidores gestionados y el servidor de administración en el sitio secundario.
Como usuario oracle, utilice Oracle Data Guard Broker en el host de la base de datos primary y vuelva a convertir el secundario en una base de datos física en espera.
Necesitará la contraseña del sistema y el nombre único de la base de datos primaria.
```
[oracle@dbhost1 ~]$ dgmgrl sys/your_sys_password@primary_db_unqname
    DGMGRL> convert database secondary_db_unqname to physical standby
```
Utilice show configuration para verificar la conversión.
Revierta los archivos /etc/hosts actualizados.
Si ha actualizado cualquier archivo /etc/hosts en un cliente para que apunte al sitio secundario para las validaciones, vuelva a revertir para que el nombre de front-end virtual apunte de nuevo a la dirección IP de front-end principal.

Nota:

ORA-01403: no se han encontrado datos con errores ORA-06512

Al validar la ubicación secundaria como se describe aquí (sin realizar una operación de switchover completa, es decir, simplemente abrir la base de datos en espera en modo de instantánea en espera) "ORA-01403: no se han encontrado datos ORA-06512" pueden aparecer errores en los logs de los servidores SOA en espera. Estos errores están relacionados con el trabajo de depuración automática de SOA. Estos errores surgen porque los trabajos de la base de datos pueden tener dependencias de roles de base de datos (se definen para activarse solo cuando la base de datos tiene el rol principal). Se trata de un comportamiento esperado y deseado que evita que los trabajos se ejecuten dos veces (una vez en la base de datos primaria y otra en la base de datos en espera). El trabajo de depuración automática de SOA se define con el rol principal, por lo que no se muestra en la vista DBA_SCHEDULER_JOBS cuando la base de datos está en modo de instantánea en espera. La opción database_role definida para cada trabajo se puede ver en la vista DBA_SCHEDULER_JOB_ROLE. En resumen, estos errores se pueden ignorar siempre que aparezcan en el sistema en espera. El trabajo del programador para la depuración automática de SOA se ejecutará en la base de datos si la instancia cambia su rol a PRIMARY y solo si lo hace.

Realización de un switchover

Un switchover es una operación planificada en la que un administrador revierte los roles de los dos sitios. Después de un switchover, el sistema principal pasa a ser secundario y el sistema secundario pasa a ser principal. Si se realiza un switchover, se producirá un tiempo de inactividad en la ubicación principal.

Antes de realizar un switchover en una configuración de DR híbrida de SOA, propague los cambios de configuración pendientes. Asegúrese de que no haya cambios replicados en el sitio secundario pendientes.

Desactive cualquier replicación programada mientras se realiza el switchover, ya que puede fallar e interferir con la propia operación de switchover.
Pare los sistemas Oracle HTTP Server en la ubicación principal.
Pare los servidores de la ubicación principal.
Utilice la consola o los scripts del servidor de administración WebLogic para parar los servidores WebLogic en la ubicación principal.

Nota:
El servidor de administración del sitio principal puede permanecer activo durante el switchover. Sin embargo, se recomienda detenerlo cuando el sitio tenga un rol en espera porque se espera que la configuración de dominio en el sitio en espera se sustituya por la configuración principal durante el ciclo de vida. Si el servidor de administración está activo mientras esto ocurre, se ejecutará con una configuración obsoleta.
Switchover del nombre de DNS de front-end.

Realice la transferencia de DNS necesaria en el servidor DNS que aloja los nombres utilizados por el sistema o modifique la resolución del host de archivos en los clientes para que apunte el nombre virtual front-end del sistema a la IP pública utilizada por el equilibrador de carga en el sitio secundario.

En los escenarios en los que se utiliza DNS para la resolución de front-end externa (como OCI DNS o DNS comercial), puede utilizar una API para impulsar el cambio. Para ver un ejemplo que transfiera este cambio en un DNS de OCI, vaya a GitHub, por ejemplo, scripts.

Tenga en cuenta que el valor TTL de la entrada DNS afectará al RTO del switchover: si el TTL es alto (ejemplo, 20 minutos), el cambio de DNS tardará ese tiempo en ser efectivo en los clientes. El uso de valores TTL más bajos hará que esto sea más rápido; sin embargo, esto puede causar una sobrecarga porque los clientes golpearán el DNS con más frecuencia en lugar de utilizar nombres almacenados en caché. Un buen enfoque es definir la TTL en un valor bajo temporalmente (por ejemplo, 1 min), antes del cambio en el DNS. A continuación, realice el cambio y, una vez finalizado el procedimiento de switchover, vuelva a revertir la TTL a su valor original.
Como usuario oracle, utilice Oracle Data Guard Broker en el host de la base de datos primaria para realizar el switchover de la base de datos.
Necesitará la contraseña del sistema y el nombre único de la base de datos primaria.
```
[oracle@dbhost1~]$ dgmgrl sys/your_sys_password@primary_db_unqname
DGMGRL> switchover to secondary_db_unqname
```
Si aún no están activos, inicie los sistemas Oracle HTTP Server en el sitio secundario (nuevo principal).
Inicie el servidor de administración en el sitio secundario (nuevo principal) o reinicie el servidor si ya se ha iniciado.
Al iniciar el servidor de administración, se activan los cambios de configuración que se replicaron mientras se trataba de una base de datos en espera en vigor.
Inicie los servidores gestionados secundarios en el sitio secundario (nuevo principal).
Utilice la consola o los scripts WebLogic para iniciar los servidores gestionados secundarios.