Desde la versión 11g, la posibilidad de descargar los backups RMAN en una BD standby física (no aplica en standby lógica) es completa, pudiendo hacer copia del controlfile para recuperar cualquier rol Data Guard (primaria o standby). Podemos por lo tanto hacer copias de la BD en una standby sin preocuparnos de cómo generar, de ser necesario, un controlfile CURRENT en un escenario de disaster recovery de producción, ya que Oracle gestionará de manera automática y transparente la conversión de rol que sea necesaria (aplica también a una standby a partir de un controlfile current). Como requisito, debemos configurar correctamente las BDs primaria y standby en el catálogo RMAN, importante para una correcta ejecución de los backups y escenarios de recuperación en esta configuración. Esta funcionalidad de intercambio de roles de controlfile entre primaria y standby aparece documentada desde la versión 11.1 de base de datos. En esta documentación se indica que los metadatos almacenados en el catálogo RMAN permiten hacer un seguimiento correcto de todos los nombres de los ficheros de las BDs que componen la configuración Data Guard, haciendo posible el intercambio de datafiles y controlfiles.

Recientemente, haciendo una validación de restore cruzado a un nuevo servidor en un cliente, encontré con que aparentemente esta premisa no se cumplía, y la restauración del controlfile mantenía el nuevo controlfile de la BD como standby. Tras diferentes pruebas y consulta de información y de notas Metalink, encontramos que el problema venía derivado del bug 18455956, que en realidad sólo se presenta en un escenario en el que la restauración del controlfile es ejecutado sin conexión al catálogo RMAN, que era justo la prueba que queríamos validar haciendo una apertura con resetlogs sin con ello impactar al resto de la configuración Data Guard registrada en el mismo catálogo, evitando añadir una nueva encarnación “falsa” derivada de esta prueba. El objetivo global era validar un escenario en el que derivar todas las tareas de backup a una BD standby, pero este problema me hizo plantear la posibilidad de tener que hacer backups del controlfile primario (ayudado, todo sea dicho, por un error en la documentación de certificación Fecha Guard de Oracle University donde se indicaba que los controlfiles no son intercambiables entre primary y standby).

Para verificar las posibilidades reales, creamos una BD single instance en un servidor con una standby física en otro. Para simplificar las cosas, las dos máquinas son en realidad un clúster con Grid Infrastructure, que comparten acceso a un filesystem ACFS montado en /acfs/desdata. La BD primaria tiene por nombre alberto y la standby bertodg (nomenclatura de Sergio la quien debo agradecer que montara este contorno en un tiempo récord con su magia usando gdbClone!). Antes de hacer las pruebas de restauración, ejecutamos en bertodg (standby) simplemente el comando backup database que hizo un backup a la FRA configurada en el mismo filesystem. Por lo tanto es un escenario sencillo donde los backups de las BDs están disponibles en los dos entornos sin necesidad de copiar datos previamente o tenerlos que recatalogar antes de restaurar.

Restauración de BD primaria con copia de standby usando conexión a catálogo RMAN

Conectados a la BD alberto (primaria) y al catálogo, en esta prueba el script RMAN restaura explícitamente el controfile del backup hecho previamente en la BD bertodg (standby). Pese a ser un standby controlfile, y sin especificar nada en el comando RMAN, este es restaurado de manera automática como un current controlfile válido para una BD primaria.

Restauración de BD primaria con copia de standby sin conexión a catálogo RMAN

Repetimos la prueba anterior, pero esta vez sin conectar al catálogo RMAN. Funcionan la restauración y la recuperación, pero no es posible abrir la BD porque el controlfile no fue modificado por Oracle durante el proceso y sigue marcado como standby.

Verificamos que el controlfile no fue transformado en CURRENT durante la operación de RESTORE CONTROLFILE.

Bug 18455856

Parece lógico que al no contar con el catálogo no sea posible tomar la decisión de convertir un controlfile a un tipo diferente del momento en el que se hizo backup, ya que Oracle no tiene la referencia del rol que desempeña la BD que restauramos dentro de la configuración Data Guard. De hecho, para cubrir este hecho, el comando RESTORE CONTROLFILE puede ser empleado, ya desde 11gR1, en 3 posibles variantes:

  • RESTORE CONTROLFILE. El controlfile es restaurado en la BD a la que estamos conectado y su tipo será determinado en función del rol asignado a la BD en el catálogo RMAN al que estamos conectados. La BD sobre la que estamos trabajando mantendrá el mismo rol que tenía registrada en el catálogo antes de iniciar la recuperación.
  • RESTORE PRIMARY CONTROLFILE. Con este comando forzamos que el controlfile que restauramos, sea un backup de una primary o de una standby, sea configurado para su uso en una BD primaria.
  • RESTORE STANDBY CONTROLFILE. El controlfile restaurado será configurado cómo STANDBY independientemente del rol que tuviera la BD desde la que fue hecho el backup.

De este modo, tenemos la opción de restaurar un controlfile de manera automática manteniendo el rol original si conectamos a un repositorio RMAN, y tenemos la opción de hacer una conversión específica en caso de que vayamos a cambiar el rol de la BD o de que no podamos determinarlo de manera automática al no conectar al catálogo. Si consultamos la nota Step by Step method to create Primary/Standby Database from Standby Backup (Doc ID 1604251.1), vemos que, como consecuencia de la correción del bug 7553431, aparece un nuevo bug, el 18455956. Sin el correspondiente parche aplicado, el comando RESTORE PRIMARY CONTROLFILE no hace la conversión necesaria si no estamos empleando un catálogo RMAN cuando recuperamos una copia hecha en una standby. Si conectamos al catálogo RMAN (workaround propuesto en el bug), desaparece el problema.

En nuestro escenario, comprobamos que el parche 18455956 no está instalado, con un nivel de PSU de abril de 2017.

Al ser así, podemos verificar que la restauración falla cuando no empleamos catálogo, incluso especificando la opción PRIMARY, como podemos ver en la siguiente prueba:

Alternativas sin uso de catálogo

Ahora que conocemos tanto el problema como su alcance, podemos emplear diferentes alternativas como solución. La primera pasa por recrear el controfile desde la propia BD standby para la recuperación de la BD primaria.

Puede resultar interesante saber que la BD standby que hemos recuperado puede ser abiera en modo sólo lectura.

Otra solución pasa por la apertura de la BD recuperada, que será una standby, como una BD primaria, forzando un failover de la misma. Previamente para evitar errores eliminamos los standby logs y también deshabilitamos flashback database, para evitar errores durante la apertura en el intento de habilitar flashback database.

Resumen

Debemos emplear catálogo RMAN siempre para hacer copias en un entorno Data Guard. Pese a ello, hay escenarios, como una prueba de restauración para convalidar los procedimientos internos de backup, en las que nos puede interesar evitar el uso del catálogo para no interferir en la configuración real de las copias. En casos como éste, debemos ser conscientes, si estamos en la versión 11.2.0.4 (no afecta a 11.2.0.3 o anteriores), de la existencia del bug 18455856 por lo que tendremos que optar, bien por la aplicación del correspondiente parche, bien por la procedimentación del escenario habida cuenta la limitación en la conversión a primary controlfile cuando no nos conectamos al catálogo RMAN.

Créditos

Ilustración: Alicia Constela

%d bloggers like this: