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.
Excelente documento, muy claro y preciso. Para mi ha sido muy ùtil.
Gracias Juan