Oracle Database Service on Bare Metal (Parte 2): Data Guard

En esta segunda entrega vamos a desplegar un entorno de contingencia para la Base de Datos AKITA, creada en el primer post de esta serie de cinco (Oracle Database Servie on Bare Metal: Getting Started).

 

Lo primero que tenemos que tener claro es que, para poder generar un Data Guard, necesitaremos un Sistema de Base de Datos ya creado.

Para crear este nuevo sistema, utilizaremos la misma metodología que en la Base de Datos primaria AKITA, pero teniendo en cuenta que esta Base de Datos se va a destruir y únicamente se conservará dicho Sistema (Servidor, Clusterware y ASM).

 

Para este caso, ya se ha provisionado un Sistema con una Base de Datos llamada ORCL. Ahora lo primero que haremos es destruir la Base de Datos, puesto que no es necesaria.

 

Como podemos ver en este ejemplo, el Availability Domain es EU-FRANKFURT-1-AD-2 y la Base de Datos se llama ORCL.

Con la sentencia Terminate borraremos la Base de Datos en todos los registros de la configuración.

Tras unos cuantos minutos, la Base de Datos ya se habrá borrado y temporalmente aparecerá con un tono gris para luego desaparecer del todo.

 

Creación del Oracle Data Guard

 

Para lanzar la configuración nos vamos a posicionar sobre la Base de Datos Primaria (AKITA) y pulsamos el Link Data Guard Asssociations

 

Esto nos llevará a un menú en el que, con unos cuantos parámetros, podremos lanzar la configuración de Oracle Data Guard.

 

 

En este ejemplo podemos ver que lo único que tenemos que seleccionar es el Sistema de Base de Datos, que soportará nuestro Oracle Data Guard y el password de SYS.

Con lo anterior, solo nos queda pulsar Enable.

Este proceso desencadena una serie de JOBS, que podemos seguir desde el Sistema Operativo, tanto el el AD 1 como en el 2:

 

 

Y después de unos cuantos minutos más, ya disponemos de nuestra configuración de Oracle Data Guard.

 

 

Si lo que queremos es verificar la configuración, como hemos hecho toda la vida, aún lo podemos hacer. Para esto entramos en el servidor de cualquiera de las dos Bases de Datos y ejecutamos show configuration desde DGMGRL.

 

Switchover Data Base

 

Pues parece que todo es correcto, solo nos queda validar la configuración con una prueba de Switchover.

Para ejecutar un Switchover necesitamos posicionarnos sobre la Base de Datos primaria, pulsar “Data Guard Associations” y luego desde el menú desplegable “Switchover”

 

Si estamos siguiendo los logs de Base de Datos, veremos que el proceso de Switchover tarda un tiempo en desencadenarse. Esto es porque primero hace una serie de verificaciones antes de ejecutar el Switchover.

El proceso de Switchover también lo podemos ejecutar a mano como siempre:

 

[code language=”bash”]

DGMGRL> show configuration verbose ;

Configuration – AKITA_fra13x_AKITA_fra2nc

Protection Mode: MaxPerformance
Members:
AKITA_fra13x – Primary database
AKITA_fra2nc – Physical standby database

Properties:
FastStartFailoverThreshold = ’30’
OperationTimeout = ’30’
TraceLevel = ‘USER’
FastStartFailoverLagLimit = ’30’
CommunicationTimeout = ‘180’
ObserverReconnect = ‘0’
FastStartFailoverAutoReinstate = ‘TRUE’
FastStartFailoverPmyShutdown = ‘TRUE’
BystandersFollowRoleChange = ‘ALL’
ObserverOverride = ‘FALSE’
ExternalDestination1 = ”
ExternalDestination2 = ”
PrimaryLostWriteAction = ‘CONTINUE’

Fast-Start Failover: DISABLED

Configuration Status:
SUCCESS

DGMGRL> switchover to ‘AKITA_fra2nc’ ;
Performing switchover NOW, please wait…
Operation requires a connection to instance “AKITA” on database “AKITA_fra2nc”
Connecting to instance “AKITA”…
Connected as SYSDBA.
New primary database “AKITA_fra2nc” is opening…
Oracle Clusterware is restarting database “AKITA_fra13x” …
Switchover succeeded, new primary is “AKITA_fra2nc”
DGMGRL> show configuration verbose ;

Configuration – AKITA_fra13x_AKITA_fra2nc

Protection Mode: MaxPerformance
Members:
AKITA_fra2nc – Primary database
AKITA_fra13x – Physical standby database

Properties:
FastStartFailoverThreshold = ’30’
OperationTimeout = ’30’
TraceLevel = ‘USER’
FastStartFailoverLagLimit = ’30’
CommunicationTimeout = ‘180’
ObserverReconnect = ‘0’
FastStartFailoverAutoReinstate = ‘TRUE’
FastStartFailoverPmyShutdown = ‘TRUE’
BystandersFollowRoleChange = ‘ALL’
ObserverOverride = ‘FALSE’
ExternalDestination1 = ”
ExternalDestination2 = ”
PrimaryLostWriteAction = ‘CONTINUE’

Fast-Start Failover: DISABLED

Configuration Status:
SUCCESS

[/code]

 

Si ahora revisamos la consola de Cloud, veremos como ya se han actualizado los Roles de cada una de las Bases de Datos.

Consideraciones

 

La configuración que lanzamos desde la consola Cloud es básica y no nos permite implementar Fast Start Failover o FarSync, sin embargo, estas configuraciones las podemos implementar de forma tradicional.

Por ejemplo, para desplegar un Observer o una Instancia FarSyn podríamos provionar in IaaS y en este servidor desplegar estas configuraciones.

Recordad que FarSync no requiere disponer de una Licencia activa de DDBB.

Evolución, innovación y transformación
35 especializaciones avaladas por Oracle
Oportunidades ilimitadas
El equipo marca la diferencia
Posts 100% Oracle
Sigue nuestro día a día