Operaciones de Switchover, Failover y Reinstate en Oracle Data Guard para el servicio Oracle Cloud de base de datos.

Por Jorge Zorrilla, Skant Gupta Oracle ACE, Joel Pérez Oracle ACE director
Publicado en Abril 2019

Revisado por Juan Pablo Guizado




En nuestro último artículo, creamos una arquitectura de base de datos Cloud con las soluciones de Oracle RAC y Data Guard.  Ahora vamos a explicar paso a paso como realizar las operaciones de Switchover, Failover y Reinstate, sobre la arquitectura creada, utilizando el utilitario raccli.





1 OPERACIÓN SWITCHOVER


La operación Switchover permite cambiar los roles de la base de datos primaria con la de contingencia. No existe perdida de datos durante la ejecución de un Switchover.  
Finalizado el Switchover, cada base de datos continua en la configuración Oracle Data Guard con roles invertidos.

Las operaciones de Switchover se realizan normalmente para reducir ventanas de mantenimiento planificadas en los nodos primarios como parchado de Hardware, sistemas operativos y hasta la propia base de datos (Rolling Upgrade)



Pasos para realizar Switchover con el utilitario raccli

Para poder realizar la operación de Switchover en la configuración Data Guard, es necesario ejecutar el comando raccli con la opción switchover dataguard. Es posible ejecutar este comando desde cualquier nodo de la base de datos primaria o de contingencia.

Cuando el comando Switchover finaliza de manera exitosa, los roles de ambas bases de datos son intercambiados.  La base de datos con el rol primario, tendrá el rol de contingencia y la base de datos con rol de contingencia, el rol primario. Ambas bases de datos se mantienen en la misma configuración Data Guard.


Los pasos para realizar Switchover son:


1.1 Nos conectamos a un nodo de la base de datos de contingencia (que obtendrá el nuevo rol primario) con el usuario opc

Using username "opc".
Authenticating with public key "rsa-key-20170425"
Passphrase for key "rsa-key-20170425":
[opc@racdg-dg01-1 ~]$
Code 07



1.2 Iniciamos la operación Switchover.

[opc@racdg-dg01-1 ~]$ raccli switchover dataguard
{
  "jobId" : "3",
  "joburi" : "http://localhost:7070/dcs/3/responses",
  "requestStatus" : "SUCCESS"
}
Code 08

 




1.3 Revisamos el estado de las bases de datos y sus actuales roles.

[opc@racdg-dg01-1 ~]$ raccli status dataguard
{
"requestStatus" : "SUCCESS",
"jobStatus" : "SUCCESS",
"instances" : [ {
    "DATABASE_NAME" : "orcldg02",
    "DATABASE_TYPE" : "PRIMARY",
    "PROTECTION_MODE" : "MaxPerformance",
    "TRANSPORT_MODE" : "ASYNC",
    "OPEN_MODE" : "READ WRITE",
    "ACTIVE_SESSIONS" : "1",
    "PENDING_APPLY_LOG_CNT" : "3",
    "ADDITIONAL_MESSAGES" : "",
    "db_instances" : [ {
      "INSTANCE_NAME" : "orcl1",
      "HOST_NAME" : "racdg-dg02-1",
      "IP" : "129.152.159.251"
    }, {
      "INSTANCE_NAME" : "orcl2",
      "HOST_NAME" : "racdg-dg02-2",
      "IP" : "129.152.159.106"
    } ]
  }, {
    "DATABASE_NAME" : "orcldg01",
    "DATABASE_TYPE" : "PHYSICAL STANDBY",
    "PROTECTION_MODE" : "MaxPerformance",
    "TRANSPORT_MODE" : "ASYNC",
    "OPEN_MODE" : "READ ONLY WITH APPLY",
    "ACTIVE_SESSIONS" : "3",
    "APPLY_LAG" : "0 seconds (computed 9 seconds ago)",
    "APPROXIMATE_ROLE_TRANSITION_TIME" : "0 seconds (computed 9 seconds ago) + 30 sec",
    "TRANSPORT_LAG" : "0 seconds (computed 8 seconds ago)",
    "ADDITIONAL_MESSAGES" : "",
    "db_instances" : [ {
      "INSTANCE_NAME" : "orcl1 (apply instance)",
      "HOST_NAME" : "racdg-dg01-1",
      "IP" : "129.144.152.186"
    }, {
      "INSTANCE_NAME" : "orcl2",
      "HOST_NAME" : "racdg-dg01-2",
      "IP" : "129.144.152.159"
    } ]
  } ]
}
[opc@racdg-dg01-1 ~]$
Code 09




 

2. OPERACIÓN FAILOVER


La operación Failover toma la base de datos de contingencia y la convierte al rol primario cuando la base de datos primaria deja de operar por alguna falla. Si la configuración Data Guard se encuentra en modo Maximum Protection o Maximum Availability antes de la caída de la base de datos primaria, es posible que se pueda perder información. 

La operación de Failover se acostumbra utilizar solo si la base de datos primaria dejar de brindar servicio y no es posible volver a restaurarlo en un periodo de tiempo razonable.

Si se logra recuperar la base de datos primaria y Flashback Database se encuentra activo, es posible reinsertar la base de datos a la configuración Data Guard con el rol de contingencia.



Pasos para realizar Failover con el utilitario raccli

Para poder realizar la operación de Failover en la configuración Data Guard, es necesario ejecutar el comando raccli con la opción failover dataguard. Es necesario ejecutar este comando desde cualquier nodo de la base de datos de contingencia que va a tomar el rol primario.

Cuando el comando Failover finaliza de manera exitosa, la base de datos primaria deja de pertenecer a la configuración Data Guard y la base de datos de contingencia asume el rol primaria.


Los pasos para realizar Failover son:


2.1 Nos conectamos a un nodo de la base de datos de contingencia, que obtendrá el nuevo rol Primario, con el usuario opc

Using username "opc".
Authenticating with public key "rsa-key-20170425"
Passphrase for key "rsa-key-20170425":
[opc@racdg-dg01-1 ~]$
Code 10



2.2 Iniciamos la operación Failover.

[opc@racdg-dg01-1 ~]$ raccli failover dataguard

{
  "jobId" : "4",
  "joburi" : "http://localhost:7070/dcs/4/responses",
  "requestStatus" : "SUCCESS"
}
[opc@racdg-dg01-1 ~]$
Code 11



2.3 Revisamos el estado de la nueva base de datos primaria.

[opc@racdg-dg01-1 ~]$ raccli status dataguard
{
  "requestStatus" : "SUCCESS",
  "jobStatus" : "SUCCESS",
  "instances" : [ {
    "DATABASE_NAME" : "orcldg01",
    "DATABASE_TYPE" : "PRIMARY",
    "PROTECTION_MODE" : "MaxPerformance",
    "TRANSPORT_MODE" : "ASYNC",
    "OPEN_MODE" : "READ WRITE",
    "ACTIVE_SESSIONS" : "2",
    "PENDING_APPLY_LOG_CNT" : "",
    "ADDITIONAL_MESSAGES" : "",
    "db_instances" : [ {
      "INSTANCE_NAME" : "orcl1",
      "HOST_NAME" : "racdg-dg01-1",
      "IP" : "129.144.152.186"
    }, {
      "INSTANCE_NAME" : "orcl2",
      "HOST_NAME" : "racdg-dg01-2",
      "IP" : "129.144.152.159"
    } ]
  }, {
    "DATABASE_NAME" : "orcldg02",
    "DATABASE_TYPE" : "REINSTATE",
    "ADDITIONAL_MESSAGES" : "ORA-16661: the standby database needs to be reinstated",
    "db_instances" : [ {
      "INSTANCE_NAME" : "orcl1",
      "HOST_NAME" : "racdg-dg02-1",
      "IP" : "129.152.159.251"
    }, {
      "INSTANCE_NAME" : "orcl2",
      "HOST_NAME" : "racdg-dg02-2",
      "IP" : "129.152.159.106"
    } ]
  } ]
}
[opc@racdg-dg01-1 ~]$
Code 12




 

3. OPERACIÓN REINSTATE (reinsertar) DE LA BASE DE DATOS PRIMARIA FALLIDA


Luego de haber ejecutado la operación Failover sobre la base de datos de contingencia, es posible restaurar la configuración de alta disponibilidad reinsertando la base de datos primaria que falló inicialmente.  Puedes utilizar los comandos de Data Guard broker para convertir la base de datos primaria fallida en una nueva base de datos de contingencia.



Pasos para realizar Reinsertar la base de datos primaria fallida con el utilitario raccli

Para poder realizar la operación de Reinstate sobre la base de datos primaria fallida, es necesario ejecutar el comando raccli con la opción reinstate dataguard. Es necesario ejecutar este comando desde la actual base de datos primaria.

Cuando el comando Reinste finaliza de manera exitosa, la base de datos primaria fallida es reinsertada como nuevo miembro de la configuración Data Guard en el rol de base de datos de contingencia. 
Cuando se revisa el estado de la configuración Data Guard y se observa el mensaje ORA-16661, es señal de que se puede ejecutar el comando Reinstate.

ORA-16661: the standby database needs to be  reinstated indicates the standby database 
can be reinstated.


Los pasos para realizar Reinstate sobre la base de datos primaria fallida son


3.1 Nos conectamos a un nodo de la base de datos dentro de la configuración Data Guard con el usuario opc

Using username "opc".
Authenticating with public key "rsa-key-20170425"
Passphrase for key "rsa-key-20170425":
[opc@racdg-dg01-1 ~]$ 
Code 13



3.2 Iniciamos la operación Reinstate sobre la base de datos primaria fallida.

[opc@racdg-dg01-1 ~]$ raccli reinstate dataguard

{
  "jobId" : "5",
  "joburi" : "http://localhost:7070/dcs/5/responses",
  "requestStatus" : "SUCCESS"
}
[opc@racdg-dg01-1 ~]$
Code 14



3.3 Revisamos el estado y rol de las bases de datos dentro de la configuración.

[opc@racdg-dg01-1 ~]$ raccli status dataguard
{
  "requestStatus" : "SUCCESS",
  "jobStatus" : "SUCCESS",
  "instances" : [ {
    "DATABASE_NAME" : "orcldg01",
    "DATABASE_TYPE" : "PRIMARY",
    "PROTECTION_MODE" : "MaxPerformance",
    "TRANSPORT_MODE" : "ASYNC",
    "OPEN_MODE" : "READ WRITE",
    "ACTIVE_SESSIONS" : "2",
    "PENDING_APPLY_LOG_CNT" : "",
    "ADDITIONAL_MESSAGES" : "",
    "db_instances" : [ {
      "INSTANCE_NAME" : "orcl1",
      "HOST_NAME" : "racdg-dg01-1",
      "IP" : "129.144.152.186"
    }, {
      "INSTANCE_NAME" : "orcl2",
      "HOST_NAME" : "racdg-dg01-2",
      "IP" : "129.144.152.159"
    } ]
  }, {
    "DATABASE_NAME" : "orcldg02",
    "DATABASE_TYPE" : "PHYSICAL STANDBY",
    "PROTECTION_MODE" : "MaxPerformance",
    "TRANSPORT_MODE" : "ASYNC",
    "OPEN_MODE" : "READ ONLY WITH APPLY",
    "ACTIVE_SESSIONS" : "5",
    "APPLY_LAG" : "16 seconds (computed 2 seconds ago)",
    "APPROXIMATE_ROLE_TRANSITION_TIME" : "16 seconds (computed 2 seconds ago) + 30 sec",
    "TRANSPORT_LAG" : "0 seconds (computed 2 seconds ago)",
    "ADDITIONAL_MESSAGES" : "",
    "db_instances" : [ {
      "INSTANCE_NAME" : "orcl1 (apply instance)",
      "HOST_NAME" : "racdg-dg02-1",
      "IP" : "129.152.159.251"
    }, {
      "INSTANCE_NAME" : "orcl2",
      "HOST_NAME" : "racdg-dg02-2",
      "IP" : "129.152.159.106"
    } ]
  } ]
}
[opc@racdg-dg01-1 ~]$
Code 15



Conclusión


Como hemos visto en este artículo, mediante un solo comando con el utilitario raccli, es posible realizara las operaciones de Switchover, Failover y Reinstate de manera muy rápida.

El servicio Oracle Cloud de base de datos es suficientemente robusto para brindarnos una arquitectura de alta disponibilidad y con una administración de la misma muy sencilla.

Esperamos que el articulo haya sido de su utilidad y los invitamos a compartirlo con la comunidad.




Ing. Jorge Zorrilla. Es un especialista IT en tecnologías Oracle e instructor de cursos oficiales de certificación Oracle. Con más de 9 años de experiencia en soluciones con tecnología Oracle como Alta Disponibilidad, Continuidad de negocios y Modernización de la infraestructura. Fue uno de los primeros especialistas en Latinoamérica en obtener la certificación Oracle Maximum Availability 12c. 
En la actualidad Jorge Zorrilla se dedica a mantener relaciones estratégicas con sus clientes en Perú mediante su empresa IDB Consulting.

Joel Pérez es un experto DBA (Oracle ACE Director, Maximum Availability OCM, OCM Cloud & OCM12c/11g) con más de 17 años de experiencia real en el mundo de la tecnología Oracle, especializado en diseño e implementación de soluciones de: Nube, Alta disponibilidad, Recuperación contra desastres, Upgrades, Replicación y toda área relacionada con bases de datos Oracle. Orador habitual en eventos internacionales de materia Oracle. Escritor de artículos para OTN español, portugués e Inglés. Joel se desempeña actualmente como: Database Cloud Solution Architect & International Business Manager para la compañía http://en.enmotech.com/ Yunhe Enmo (Beijing) Technology Co. Ltd. Beijing, China. LinkedIn: https://www.linkedin.com/in/sirdbaasjoelperez/ & Joel Pérez’s Blog: ttp://blog.enmotech.com/

Skant Gupta es un Oracle ACE, Maximum Availability OCM, OCM Cloud & OCM12c/11g, Oracle 12c & 11g RAC Certified, se desempeña como Senior DBA en Etisalat, Dubai. Más de 5 años en diversas tecnologías de Oracle, focalizado principalmente en bases de datos, soluciones de alta disponibilidad, weblogic y GoldenGate. Podrá seguirlo en su
blog: http://oracle-help.com

Este artículo ha sido revisado por el equipo de productos Oracle y se encuentra en cumplimiento de las normas y prácticas para el uso de los productos Oracle.