Oracle Database 12c: Oracle Data Guard 12cR1 “Far Sync Standby”

Por Joel Pérez y Wissem El Khlifi
Publicado en septiembre 2013

Introducción:

En el siguiente artículo trataremos de mostrar que funcionalidades o mejoras que “Oracle Data Guard” nos aporta para la nueva versión de bases de datos 12c.

Este artículo destaca las novedades o funcionalidades de “Dataguard” que han cambiado en la nueva versión 12c.

Este artículo también puede ser útil a aquellos administradores de bases de datos responsables de alta disponibilidad de los sistemas de bases de datos.

Qué es Oracle “Dataguard” ?

La solución Oracle “Dataguard” ofrece un servicio de alta disponibilidad de bases de datos Oracle.

Se trata de un servidor primario (puede ser de múltiple nodos en el caso de “RAC”), uno o más servidores segundarios llamados también “Standby Database”. Los servidores en “Standby” sirven para proteger los datos en casos de fallas, errores, pérdida o corrupción en el servidor primario.

Se puede abrir la base de datos en modo “Standby” para consultas, pruebas, informes.

Cuales son las novedades en Oracle “Data Guard” 12cR1?

1- “Far Sync Standby”:

a. Introducción:

En las versiones anteriores a Oracle 12c, una “Standby Database” en cascada recibe los “redo logs” a partir de una base de datos en “Standby, no de la base de datos primaria.

La base de datos “Standby”, que sirve a la base de datos “Standby” en cascada, se crea a partir de la base de datos primaria utilizando RMAN (duplicación en activo) o desde una copia de seguridad de la primaria.

La siguiente imagen muestra una base de datos primaria enviando datos de “redo” hacia una base de datos en “Standby” física y a una base de datos “Standby” lógica. La base de datos Standby” física retransmite los datos “redo” a una otra base de datos “Standby”física (“Cascading Standby 1”).

La base de datos en “Standby” lógica retransmite los datos redo en forma de sentencias “SQL” a una otra base de datos “Standby” física (“Cascading Standby 2”).

Las bases de datos en “Standby” física y lógica son bases de datos con ficheros de “control file”, ficheros de parámetros (“Spfile”), ficheros de datos etc.…

La nueva versión de Oracle 12cR1 viene con un nuevo role de “Standby Database” llamado “Far Sync Standby”. La nueva servidora de “Standby” funciona como un coordinador entre la primaria y todas sus bases de datos “Standby”.

“Far Sync Standby” es un “Standby” en cascada que sirve como un repositorio de archivos de log.

“Far Sync Standby” solo puede contener ficheros de “control file”, ficheros de parámetros (“Spfile”), archivos “Standby “de log y no posee ningún fichero de datos (“datafiles”). No se puede abrir la “Far Sync Standby”, no puede aplicar los “redo” log, no puede tener el role de servidor primario y no puede ser convertida a otro tipo de “Standby Database”.

EL servidor de “Far Sync Standby” puede ser de recursos muy limitados (en memoria, CPU,…), ya que actúa sólo como repositorio de archivos de log para otras bases de datos “Standby”.

La creación de una instancia de “Far Sync Standby” muy cerca de la base de datos primaria tiene la ventaja de:

- Tener un redo sincrónico y local garantizando cero pérdida de datos sobre todo cuando los otros servidores de “Standby Database” están muy lejos del servidor primario.
- Ganar en rendimiento en compresión de transporte redo y en servir múltiples destinos en modo asíncrono.
- Operaciones de “Switchover” y “Failover” transparentes.

“Far Sync Standby” puede operar en;

- Modo de máxima protección.
- Modo de máximo rendimiento.
- Modo de máxima disponibilidad.

La siguiente imagen muestra una base de datos primaria enviando datos de “redo” hacia una “Far Sync Standby”. “Far Sync Standby” retransmite los datos redo a las otras bases de datos “Standby” física.

b. Creación de “Far Sync Standby”:

A continuación podemos ver las etapas necesarias para la creación de “Far Sync Standby”

Prerrequisitos

- La base de datos primaria debería funcionar en modo “archive”
- La base de datos primaria y la “Far Sync Standby” deberían tener exactamente la misma versión de “Oracle Software” y con “patchs” al mismo nivel.
- “FORCE LOGGING” tiene que ser habilitado en la base de datos primaria.
- La base de datos primaria debería usar un fichero de parámetro “SPFILE”
- Existe una conectividad hacia la base de datos de “Far Sync Standby”.
- “Listener”tiene que ser configurado y funcionando en el servidor primario y servidor de “Far Sync Standby”.
- Los ficheros de “Standby redo log” deberían ser creados en la base de datos primaria. Según la siguiente formula;

Cantidad de Grupo de “Standby redo log” = Cantidad de Grupos de “redo Log” de la base de datos primaria + 1

Tamaño de un fichero de Grupo de “Standby redo log” >= Tamaño de un fichero de Grupo de “redo Log” de la base de datos primaria

Inventario

En el siguiente ejemplo, tenemos una base de datos primaria, una “Far Sync Standby” y dos bases de datos en “Standby” físico.

ROLE DB_UNIQUE_NAME
Base de datos primaria livedb
“Far Sync Standby” livefs
Base de datos en “Standby” físico livestby1
Base de datos en “Standby” físico livestby2


Creación de “Far Sync Standby”

Durante el proceso tradicional de la creación de “Standby” físico, un archivo “Standby Controlfile” debe ser creado en el servidor primario. El archivo “Standby Control file” se utiliza para montar la base de datos “Standby” físico.

Sin embargo, durante el proceso de creación “Far Sync Standby”, hay que usar un archivo de" Far Sync Standby Controlfile" para montar “Far Sync Standby”.

Se puede notar la nueva línea de comando “alter database create far sync instance controlfile”

Ejemplo:

Ejecute el siguiente comando en la base de datos primaria:

SQL> alter database create far sync instance controlfile as ‘/home/oracle/wissem/far_stby_ctl.ctl’;

Crear un alias de “TNS” para resolver “Far Sync Standby” en la base de datos primaria.

livedb =
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = livedb.domain.com)(PORT = 1521))
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = livedb)
    )
  )
 
livefs =
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = livefs.domain.com)(PORT = 1521))
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = livefs)
    )
  )

Ajuste los siguientes parámetros de inicialización de la base de datos primaria:

• log_archive_dest_1 = ‘location=USE_DB_RECOVERY_FILE_DEST’
• log_archive_dest_2 ='SERVICE=livefs SYNC COMPRESSION=ENABLE VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=livefs' (Nota: habilitamos la compression de datos “redo”)
• LOG_ARCHIVE_DEST_STATE_2=ENABLE
• log_archive_config= ’dg_config=(livedb,livefs,livestby1,livestby2)’
• log_archive_max_processes = 8

Crear un archivo de parámetros “PFILE” de la base de datos primaria:

SQL> create pfile=’/home/oracle/wissem/pfile_far_stby.ora’ from spfile;

Modifica el archivo de parámetros “PFILE” creado en el paso anterior y cambia los siguientes parámetros:

• *.control_files=‘/home/oracle/wissem/far_stby_ctl.ctl’
• *.db_unique_name=’livefs’
• log_archive_config= ’dg_config=(livedb,livefs,livestby1,livestby2)’
• *.fal_server=’livedb’
• log_archive_dest_1 = ‘location=USE_DB_RECOVERY_FILE_DEST VALID_FOR=(ALL_LOGFILES,ALL_ROLES)
• DB_UNIQUE_NAME=livefs’
• log_archive_dest_2=’ SERVICE=livestby1 VALID_FOR=(STANDBY_LOGFILES,STANDBY_ROLE) DB_UNIQUE_NAME=livestby1'
• log_archive_dest_3=’ SERVICE=livestby2 VALID_FOR=(STANDBY_LOGFILES,STANDBY_ROLE) DB_UNIQUE_NAME=livestby2'
• LOG_ARCHIVE_DEST_STATE_2=ENABLE
• LOG_ARCHIVE_DEST_STATE_3=ENABLE
• log_archive_max_processes = 8

En el servidor de “Far Sync Standby”, Crea un alias de “TNS” para resolver la base de datos primaria y las dos bases de datos en “Standby” físico.

Copia el mismo contenido “TNS” en los dos servidores de bases de datos en “Standby” físico.

livedb =
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = livedb.domain.com)(PORT = 1521))
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = livedb)
    )
  )
 
livefs =
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = livefs.domain.com)(PORT = 1521))
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = livefs)
    )
  )
Livestby1 =
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = Livestby1.domain.com)(PORT = 1521))
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = Livestby1)
    )
  )
Livestby2=
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = Livestby2.domain.com)(PORT = 1521))
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = Livestby2)
    )
  )

Inicia en modo “No Mount” la instancia de “Far Sync Standby”,

Startup nomount pfile=’/home/oracle/wissem/pfile_far_stby.ora’;

Modifica la instancia de “Far Sync Standby” hacia el modo “Mount”:

Alter database mount;

Asimismo validamos el role de la instancia de “Far Sync Standby”:

Select database_role from v$database;

Nota el resultado de la sentencia, debe mostrar “FAR SYNC STANDBY” como role de la instancia de “Far Sync Standby”.

Los ficheros de “Standby redo log” deberían ser creados en la base de datos de “Far Sync Standby”. Según la siguiente formula;

Cantidad de Grupo de “Standby redo log” = Cantidad de Grupos de “redo Log” de la base de datos primaria + 1

Tamaño de un fichero de Grupo de “Standby redo log” >= Tamaño de un fichero de Grupo de “redo Log” de la base de datos primaria

SQL> alter database add standby logfile THREAD 1 size 1G;

Compruebe los registros de archivos están bien recibidos, se puede consultar la vista: “v$archive_dest_Status”

Crear base de datos “Standby” físico

Se puede usar el mismo procedimiento de Oracle 11g para crear una base de datos en “Standby” físico:

Se puede utilizar uno de los siguientes métodos:

1. Crear manualmente a través de copias de seguridad “User Managed Backup”.
2. Usar “RMAN” para duplicar la base de datos primaria.
3. Crear una base de datos de “Standby” físico en activo sin una copia de seguridad usando “RMAN”

Copie el fichero “PFILE” desde la base de datos primaria y cambia los siguientes valores:

“Livestby1”:

• *.db_unique_name=’livestby1’
• log_archive_config= ’dg_config=(livedb,livefs,livestby1,livestby2)’
• *.fal_server=’livefs’ <= the far sync standby name.
• log_archive_dest_1 = ‘location=USE_DB_RECOVERY_FILE_DEST VALID_FOR=(ALL_LOGFILES,ALL_ROLES)
• DB_UNIQUE_NAME=livestby1’
• log_archive_dest_2=’ SERVICE=livefs VALID_FOR=(STANDBY_LOGFILES,STANDBY_ROLE) DB_UNIQUE_NAME=livefs'
• LOG_ARCHIVE_DEST_STATE_2=ENABLE
• log_archive_max_processes = 8

“Livestby2”:

• *.db_unique_name=’livestby2’
• log_archive_config= ’dg_config=(livedb,livefs,livestby1,livestby2)’
• *.fal_server=’livefs’ <= The far sync standby name.
• log_archive_dest_1 = ‘location=USE_DB_RECOVERY_FILE_DEST VALID_FOR=(ALL_LOGFILES,ALL_ROLES)
• DB_UNIQUE_NAME=livestby2’
• log_archive_dest_2=’ SERVICE=livefs VALID_FOR=(STANDBY_LOGFILES,STANDBY_ROLE) DB_UNIQUE_NAME=livefs'
• LOG_ARCHIVE_DEST_STATE_2=ENABLE
• log_archive_max_processes = 8

Para crear la base de datos “Standby” física, podemos usar a RMAN para la duplicación. Este método dejará la “Standby” física en modo “MOUNT”.

$ export ORACLE_SID = livestby1
SQL> startup nomount pfile =’pfile_location’
RMAN> connect target sys/<Password>@livedb
RMAN> connect auxiliary /
RMAN> duplicate target database for standby from active database nofilenamecheck;

Pasos posteriores a la creación de las bases de datos “Standby” física

“Standby” física esta en modo “MOUNT”, reinicie las bases de datos “Standby” física (“livestby1”, “livestby2”) usando ficheros “SPFILE”

Crea los ficheros de “Standby redo log” en las bases de datos “Standby” física:

Inicie la aplicación de “redo”:

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE PARALLEL 8 DISCONNECT;

Verifica si existe algún error:

select message, timestamp
from v$dataguard_status
where severity in ('Error','Fatal')
order by timestamp;

2- “Standby Database” en cascada en tiempo real

a. Introducción:

En las versiones anteriores a Oracle 12c, una “Standby Database” en cascada recibe los “redo logs” a partir de una base de datos en “Standby, no de la base de datos primaria.

La base de datos “Standby”, que sirve a la base de datos “Standby” en cascada, se crea a partir de la base de datos primaria utilizando RMAN (duplicación en activo) o desde una copia de seguridad de la primaria.

La propagación de “redo” al “Standby Database” en cascada terminal NO se hace en tiempo real; significa las secuencias de log están transferidas al “Standby Database” en cascada terminal solo después de un cambio de log (“Switch log”) en la base de datos primaria

Desde Oracle 12c “release” 1, ahora es posible hacer la propagación en tiempo real de toda la secuencia de log, es decir, tan pronto cuando el registro redo está escrito en el fichero “Standby log” de la base de datos en”Standby”.

b. Prerrequisitos

• La primera “Standby Database” en cascada tiene que ser una “Standby” física o bien una “Far Sync Standby Database”
• Los “Standby Redo Logs” tienen que ser creados
• La opción “Active Dataguard” tiene que ser activada.
• La opción “dg_config” del parámetro “log_archive_config” debería contener todos los valores “db_unique_name” de todas las bases de datos primaria y “Standby Database” en cascada.

c. “Standby Database” en cascada en tiempo real

Inventario

En el siguiente ejemplo, tenemos una base de datos primaria, una “Far Sync Standby” y dos bases de datos en “Standby” físico.

ROLE DB_UNIQUE_NAME
Base de datos primaria Livedb
Primera “Standby Database” en cascada (puede ser “Far Sync Standby”) Livefs
“Standby Database” Terminal livestby1
“Standby Database” Terminal livestby2


“Standby Database” en cascada en tiempo real

Configura “Standby Database” en cascada siguiendo los mismos pasos de 11g Release 2 u siguiendo los mismos pasos mencionados en el primer capítulo.

• Primero, el método de “Log Transport” debería ser "SYNC" y los archivos “Standby Redo Logs” deben estar configurados en la “Standby Database” en cascada, como se mencionaba en el capítulo anterior.

• La opción “dg_config” del parámetro “log_archive_config” debería contener todos los valores “db_unique_name” de todas las bases de datos primaria y “Standby Database” en cascada.

log_archive_config= ’dg_config=(livedb,livefs,livestby1,livestby2)’

• “log_archive_dest_n” en “Standby Database” en cascada:

‘valid_for=(STANDBY_LOGFILES,STANDBY_ROLE)’

• El parámetro “FAL_SERVER” en la primera “Standby Database” en cascada debería tener el valor de la base de datos primaria o bien cualquier otro “Standby Database”.

• El parámetro “FAL_SERVER” del “Standby Database” en cascada terminal debería tener el valor de la base de datos primaria o bien la primera “Standby Database”.

• Cambia el método de “Log Transport” en modo “ASYNC”; opción de propagación en tiempo real.

3- Usar DBMS_ROLLING para llevar a cabo “Rolling Upgrade”

La base de datos Oracle 12cR1 ofrece la posibilidad de dividir el entorno de “Dataguard” en dos grupos: el grupo “leading” (LG) y el grupo “trailing” (TG) para preparar el proceso de “Upgrade”.

El grupo líder (LG) se actualiza primero, es el grupo que contiene la futura y nueva base de datos primaria.

Durante el proceso de actualización, las bases de datos del grupo de “trailing”, que contienen la actual base de datos primaria, continúan ejecutando la “vieja” versión de software de base de datos hasta que todas las bases de datos en el grupo de “leading“(LG) se actualicen.

La nueva base de datos primaria estará sincronizada con la anterior base de datos primaria mediante la aplicación de todos los cambios que se han generado durante el proceso de actualización “Upgrade”.

El proceso de “Rolling Upgrade” garantiza una alta disponibilidad del entorno durante el proceso de “Upgrade”.

En el siguiente ejemplo usaremos el paquete DBMS_ROLLING para realizar el “rolling upgrade”.

Inventario

En el siguiente ejemplo, tenemos una base de datos primaria y dos bases de datos en “Standby” físico.

ROLE DB_UNIQUE_NAME GROUP
Base de datos primaria Livedb TG
“Standby Database” livestby1 TG
“Standby Database” livestby2 TG


• Inicializa el plan de actualización:

SQL> EXECUTE DBMS_ROLLING.INIT_PLAN (future_primary => 'livestby2');

• Construir el plan de actualización:

SQL> EXECUTE DBMS_ROLLING.BUILD_PLAN;

• Empieza “rolling upgrade”:

SQL> EXECUTE DBMS_ROLLING.START_PLAN;

• Actualiza el “LG Standby” y reinicie en modo lectura / escritura con la nueva versión de “Oracle Database software”.

• “Switchover” hacia el “LG”:

SQL> EXECUTE DBMS_ROLLING.SWITCHOVER;

• Sube al modo “MOUNT” la anterior base de datos primaria “livedb” con la nueva versión de “Oracle Database software”.

• Sube al modo “MOUNT” “Standby” “livestby1” con la nueva versión de “Oracle Database software”.

• Acabe el proceso de “rolling upgrade”:

SQL> EXECUTE DBMS_ROLLING.FINISH_PLAN;

Se puede encontrar más detalles sobre DBMS_ROLLING en el siguiente enlace: http://docs.oracle.com/cd/E16655_01/server.121/e17640/dbms_rolling_upgrades.htm#CJAEIFEB

4- El Privilegio SYSDG

Usuario otorga el privilegio “SYSDG” puede ejecutar todas las Operaciones de “Dataguard” en SQL*Plus y a través de comandos “Broker DGMGRL”.
La siguiente es una lista de los comandos que un usuario con el privilegio “SYSDG” puede ejecutar:

• STARTUP
• SHUTDOWN
• ALTER DATABASE
• ALTER SESSION
• ALTER SYSTEM
• CREATE RESTORE POINT (including GUARANTEED Restore Points)
• CREATE SESSION
• DROP RESTORE POINT (including GUARANTEED Restore Points)
• FLASHBACK DATABASE
• SELECT ANY DICTIONARY (DBA_ Views)
• SELECT
     o X$ Tables
     o V$ and GV$ Views
     o APPQOSSYS.WLM_CLASSIFIER_PLAN
• DELETE
     o APPQOSSYS.WLM_CLASSIFIER_PLAN
• EXECUTE
     o SYS.DBMS_DRS

5- Mover ficheros de “Standby Database” Online:

En las versiones anteriores a Oracle 12c, se puede copiar y cambiar el nombre de un fichero de “Standby Database”, mientras que la recuperación “Managed Recovery”está detenida o si la “Standby Database” física está abierta en modo SÓLO LECTURA utilizando RMAN, SQL * Plus o líneas de comando “OS” y fichero de “Standby Database” esta “OFFLINE”.

Desde la versión Oracle 12c “release” 1, es posible mover un fichero de “Standby Database” ONLINE con el comando:

alter database move datafile '/home/oracle/wissem/data.189.782738241' to '+DATA';

6- Recuperar “Standby Database” a través de la red

Desde la versión Oracle 12c “release” 1, es posible recuperar la base “Standby Database” utilizando una copia de seguridad comprimida través de la red. El DBA puede ejecutar la recuperación “Standby Database” utilizando un nombre de servicio válido de la base de datos primaria.

Se puede ejecutar desde RMAN el siguiente comando:

rman target/
recover database from service livedb using compressed backupset;

 


Joel es un experto DBA con más de 12 años de experiencia, especializado en bases de datos con especial énfasis en la soluciones de Alta Disponibilidad & “Disaster Recovery” (RAC, Data Guard, y otras). Es un conferencista habitual en eventos de Oracle como: OTN LAD TOUR y otros. Consultor Internacional con trabajos en más de 20 países alrededor del mundo. Fue el primer latinoamericano en ser nombrado "Experto OTN" en el año 2003, Oracle ACE año 2004 y actualmente Oracle ACE Director. Wissem es un Senior DBA con más de 12 años de experiencia, especializado en soluciones RAC & Data Guard. Actualmente labora para “Schneider Electric / APC Global operations”. Wissem ha trabajado también para varias empresas internacionales líderes en sectores de Bancas, Telecomunicaciones, Internet y Energía. Wissem fue el primer Oracle ACE en España y es un OCP DBA.