jueves, 10 de abril de 2014

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;

1 comentario:

  1. buenas tardes estoy trabajando para implementar tu solucion data guard.. la verdad no soy muy bueno en esto..
    tengo problemas en esto
    SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_2 = 'SERVICE=DBSERVERDG SYNC AFFIRM VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=DBSERVERDG' SCOPE=BOTH;

    me da error
    ora-32017:fallo al actualizar spfile
    ora-00439:funcion no activada managed standby

    ResponderEliminar