Oracle Data Guard es un producto que nos asegura la alta disponibilidad, protección de datos, y un sitio alterno o disaster recovery (Standby Database) en caso de algún fallo  de carácter físico o lógico de nuestra base de datos principal. Oracle Data Guard nos ayuda a mantener estas bases de datos standby como copias de nuestra base de datos de producción, lo cual nos permite que durante mantenimientos que tienen un tiempo muy prolongado disponibilizar el servicio de nuestra base de datos, minimizando el tiempo de pérdida del servicio de nuestra base de datos comparado con el tiempo del mantenimiento programado.

La implementación del sitio de contingencia fue desarrollado en un ambiente que cuenta con las siguientes características:

SITIO PRIMARIO

• Sistema Operativo CentOS 7.5 64 bits
• Base de Datos Oracle 12c Release 2 configurada en Stand Alone
• Modo Archive activo (es necesario y obligatorio para la implementación del sitio alterno o standby)
• Conexión entre servidores sin restricciones, no hay firewall en medio de ambos.
• Almacenamiento en filesystem
• Listener configurado por defecto (puerto 1521)

SITIO STANDBY

• Sistema Operativo CentOS 7.5 64 bits
• Software Base de Datos Oracle 12c Release 2
• Almacenamiento en filesystem
• Listener configurado por defecto (puerto 1521)

Antes de iniciar con la implementación de nuestro Dataguard Físico debemos asegurarnos que existe conectividad y resolución de hostname por medio de ssh entre los servidores que intervendrán en esta configuración:

a) Edición de archivo /etc/hosts

Es muy importante que la resolución de los hostnames de los servidores que intervendrán en esta configuración se lo realice localmente por medio del archivo /etc/hosts o  por medio de un DNS.

b) Ping entre servidores 

c) Conectividad SSH

Luego de haber comprobado que la resolución de hostnames en los servidores primario y standby son correctos y que la conectividad ssh se realiza correctamente, podemos continuar con las configuraciones necesarias para crear nuestro STANDBY FISICO

1)  Base de Datos en Modo Archive

Es indispensable que nuestro sitio PRIMARIO tenga  habilitado el  MODO ARCHIVE  para que la implementación de nuestro sitio alterno o standby sea correcto debido a que Oracle Data Guard utilizará los archivelogs para aplicarlos en nuestro STANDBY, y de esta manera tener una copia exacta de nuestra base de datos PRIMARIA

2) Habilitamos FORCE LOGGING

Para garantizar la consitencia de la base de datos STANDBY debemos habilitar FORCE LOGGING a nivel de la base de datos PRIMARIA. Este característica, que viene deshabilitada por defecto, nos ayuda a que todos los cambios que se realizan dentro de la base de datos PRIMARIA sean registrado dentro de los REDO LOGS, incluso se registrará las transacciones u operaciones que tienen NOLOGGING.

3) Agregamos Standby Redo Logs en base de datos PRIMARIA

A pesar que los Standby Redo logs son exclusivos para los sitios alternos o standby, en caso de realizar un cambio de roles entre la base de datos Standby y Primaria, se los va a tener que crear almomento de realizar esta transición de roles.

4) Mapeo en tnsnames.ora

5) Cambio de parámetros inicialización en base de datos PRIMARIA

Para el correcto funcionamiento de Oracle Dataguard es necesario modifcar los siguientes parámetros de inicialización en nuestra base de datos PRIMARIA.

6) Reinicio de base de datos PRIMARIA

Para que tomen efecto los parámetros que no son dinámicos en la base de datos es necesario realizar un reinicio de la misma.

7) Creación de PFILE para STANDBY

8) Respaldo RMAN completo de la base de datos PRIMARIA

9) Creación de standby controlfile

10) Envío de respaldo RMAN, standby controlfile, pfile y password file hacia servidor de contingencia

11) Creación de directorios faltantes para base de datos STANDBY

12) Copia de Standby Controlfile

13) Edición de PFILE en servidor STANDBY

Editamos el archivo PFILE que fue enviado desde nuestro sitio PRIMARIO con los valores de acuerdo a nuestro sitio de contingencia

14) Creación de SPFILE desde PFILE editado

Creamos un SPFILE a partir del PFILE anteriormente editado, para montar la base de datos

15) Montamos la base de datos STANDBY

16) Catalogamos respaldos RMAN 

Debido a que los repaldos RMAN enviados desde el servidor PRIMARIO se encuentran en un directorio distinto al origen debemos catalogarlos nuevamente.

17) Restaruramos Base de Datos STANDBY a partir de respaldo RMAN enviado de sitio PRIMARIO

18) Renombramos Redo logs

Una vez completa la restauración de la base de datos STANDBY, debemos renombrar los redologs.

19) Recover de base de datos STANDBY

20) Recreamos standby redo logs

21) Iniciamos proceso APPLY en base de datos  STANDBY