Paso a Paso para Crear y Configurar Physical Oracle Data Guard

Si uno busca en la web acerca de como crear un entorno de alta disponibilidad usando Oracle Data Guard (también llamado Oracle Standby) va a encontrar cientos de sitios que muestran el paso a paso. Algunos sitios son muy claros y precisos y otros no tanto. Yo siempre recomiendo empezar para la documentación oficial. En esta oportunidad no solo voy a mostrar el paso a paso sino que además pretendo mostrar como activar Switchover, Failover, repasar los modos de protección disponibles, como monitorear y también algo de troubleshooting básico.

Ahora voy a compartir el Paso a Paso para armar un entorno de replicación desde desde cero. La base primaria se llama ROP y la base standby se llamará ROPDG

Configuración Inicial de Oracle Data Guard Físico (PODG)

Configuración de la base Primaria

1. Preparar la base primaria (ROP)

1.1 Habilitar la base para que funcione con archivelog

Para revisar si la base esta en modo archivelog

SQL> SELECT log_mode FROM v$database;

Si el resultado es NOARCHIVELOG, bajar la base y seguir los siguientes pasos:

SQL> STARTUP MOUNT

SQL> ALTER DATABASE ARCHIVELOG

SQL> ALTER DATABASE OPEN;

Para chequear como quedó configurado:

SQL> ARCHIVE LOG LIST;

1.2 Crear password file (si es que no existe)

$ orapwd file=filename password=password entries=max_users

1.3 Forzar el logueo de las operaciones

SQL> ALTER DATABASE FORCE LOGGING;

1.4 Setear los parámetros

Para Setear el modo de protección Maximum Availability

SQL> ALTER SYSTEM SET LOG_ARCHIVE_CONFIG='DG_CONFIG=(ROP,ROPDG)';

SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_2 = 'SERVICE=ROPDG SYNC AFFIRM VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=ROPDG' SCOPE=BOTH;

SQL> ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE AVAILABILITY;

SQL> ALTER SYSTEM SET LOG_ARCHIVE_MAX_PROCESSES = 30 SCOPE=BOTH;

SQL> ALTER SYSTEM SET STANDBY_FILE_MANAGEMENT=AUTO;

1.5 Crear los standby redo (que se usaran en Switchover)

2. Configurar el servicio en ambos servidores

Crear las entradas en los tns de ambos equipos, una entrada para primaria y otra para standby

ROP =
  (DESCRIPTION =
    (ADDRESS_LIST =
      (ADDRESS = (PROTOCOL = TCP)(HOST = host-primario)(PORT = 1521))
    )
    (CONNECT_DATA =
      (SERVICE_NAME = ROP)
    )
  )

ROPDG =
  (DESCRIPTION =
    (ADDRESS_LIST =
      (ADDRESS = (PROTOCOL = TCP)(HOST = host-standby)(PORT = 1521))
    )
    (CONNECT_DATA =
      (SERVICE_NAME = ROPDG)
    )
  )

3. Bajar la base y tomar un backup en frio (datafiles y logfiles)

4. Montar la base y crear el standby controlfile

SQL> STARTUP MOUNT
SQL> ALTER DATABASE CREATE STANDBY CONTROLFILE AS '/tmp/ctlROP2.ctl';

5. Preparar el init para la base standby

5.1
En la base primaria crear un pfile desde el spfile (si la base no tiene spfile simplemente copiar el pfile en /tmp)

SQL> CREATE PFILE='/tmp/initROP.ora' FROM SPFILE;

5.2
Editar el archivo de inicio recién creado (/tmp/initROP.ora) y cambiar los parámetros necesarios para que sirva con init de la base standby. La mayoría de los parámetros son iguales. Los que pueden cambiar son los siguientes:

DB_NAME=ROP
DB_UNIQUE_NAME=ROPDG

Configuración de la base Standby (Manual)

6. Transferir los archivos del backup, el initROPDG.ora y el pfile al servidor standby

7. Levantar el listener

8. Crear los standby redo
Los redo standby son requerimiento para poder usar real time apply:

SQL> ALTER DATABASE ADD STANDBY LOGFILE ('/u01/app/oradata/rop/stdby_redo01.log') SIZE 50M;
SQL> ALTER DATABASE ADD STANDBY LOGFILE ('/u01/app/oradata/rop/stdby_redo02.log') SIZE 50M;
SQL> ALTER DATABASE ADD STANDBY LOGFILE ('/u01/app/oradata/rop/stdby_redo03.log') SIZE 50M;
SQL> ALTER DATABASE ADD STANDBY LOGFILE ('/u01/app/oradata/rop/stdby_redo04.log') SIZE 50M;

9. Activar la aplicación de Redo en Standby

Para activar la aplicación en Real-Time

Con la base montada ejecutar:
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT;

Para activar la aplicación sin Real-Time

Con la base montada ejecutar:
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;

Para Cancelar la aplicación de Redo

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;

Failover

Si la base de datos primaria no esta disponible y la falla no tiene pronta solución (una falla critica en el hardware del equipo donde se aloja la base) será necesario activar la standby como base primaria. Luego de convertirla a primaria se recomiendo tomar un backup full

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH;
SQL> ALTER DATABASE ACTIVATE STANDBY DATABASE;

La base primaria original luego podrá pasar a ser la standby. Si se usa flashback database es podrá restaurar al momento anterior a la falla y convertirla en standby rapidamente, si no se usa flashback database habrá que realizar el setup de cero.

Switchover (Switchback)

Para Convertir la base Primaria en Standby

SQL> CONNECT / AS SYSDBA
SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO STANDBY;
SQL> SHUTDOWN IMMEDIATE;
SQL> STARTUP NOMOUNT;
SQL> ALTER DATABASE MOUNT STANDBY DATABASE;
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;

Para Convertir la base Standby en Primaria

SQL> CONNECT / AS SYSDBA
SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY;
SQL> SHUTDOWN IMMEDIATE;
SQL> STARTUP;

El switchover puede ser útil por ejemplo para aplicar parches sin tener que cortar el servicio (garantizando la continuidad de negocio). Es recomendable realizar pruebas de switchover, también probando que el transporte y aplicación de redos funciona correctamente y luego volver a realizar un switchover para dejar la base primaria en el servidor original, este proceso se llama Switchover.

Active DataGuard

Las bases standby pueden levantarse en modo read only, lo cual puede ser usado para ejecutar reportes y de esa forma descargar la base productiva o también podría usarse para tomar backup lógicos. Mientras la base esta en read only no se puede aplicar cambios, aunque los cambios se siguen transportando no se aplican y por lo tanto la base standby va quedando cada vez mas desincronizada con la base primaria. En 11g se puede configurar la base standby como activa con lo cual la base si bien sigue estando en read only aplica lo cambios que van llegando desde la primaria.

Este feature es muy interesante aunque tiene un costo extra y se tiene que licenciar por separado. Hay que tener cuidado en activarlo porque técnicamente es muy sencillo de hacer y queda registrado (chequear en DBA_FEATURE_USAGE_STATISTICS) el uso del feature con lo cual una auditoria podría constatarlo fácilmente.

Ahora voy a mostrar como activar la replica en modo activa:

SQL> SHUTDOWN IMMEDIATE;
SQL> STARTUP MOUNT;
SQL> ALTER DATABASE OPEN READ ONLY;
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;

Notar que si se activa el recover con la base en modo read only en lugar de solo montada se activa el Active DataGuard.

Monitorear Oracle Data Guard Físico (PODG)

Para chequear datos referentes a tipo y nivel de protección, rol de la base de datos y status del swithover

SQL> SELECT DATABASE_ROLE,DB_UNIQUE_NAME,OPEN_MODE,PROTECTION_MODE,
PROTECTION_LEVEL,SWITCHOVER_STATUS
FROM V$DATABASE

Para ver los archivelog que fueron aplicados:

SQL> SELECT MAX(SEQUENCE#) LAST_APPLIED_LOG FROM V$LOG_HISTORY

Para chequear el redo apply y el redo transport en el sitio standby:

SQL> SELECT PROCESS,STATUS,SEQUENCE#,BLOCK#,BLOCKS
FROM V$MANAGED_STANDBY

Para revisar eventos que disparan mensajes en el alert tanto en primaria como en standby:

SQL> SELECT MESSAGE FROM V$DATAGUARD_STATUS;