Dende a versión 11g, a posibilidade de descargar os backups RMAN nunha BD standby física (non aplica en standby lóxica) é completa, podendo facer copia do controlfile para recuperar calquera rol Data Guard (primaria ou standby). Podemos polo tanto facer copias da BD nunha standby sen preocuparnos de cómo xerar, de ser preciso, un controlfile CURRENT nun escenario de disaster recovery de producción, xa que Oracle xestionará de xeito automático e transparente a conversión de rol que sexa preciso (aplica tamén a unha standby a partires dun controlfile current). Como requisito, precisamos configurar correctamente as BDs primaria e standby no catálogo RMAN, importante para unha correcta execución dos backups e escenarios de recuperación nesta configuración. Esta funcionalidade de intercambio de roles de controlfile entre primaria e standby aparece documentada dende a versión 11.1 de base de datos. Nesta documentación indícase, que os metadatos almacenados no catálogo RMAN permiten facer un seguimento correcto de tódolos nomes dos ficheiros das BDs que compoñen a configuración Data Guard, sendo posible o intercambio de datafiles e controlfiles.

Recentemente, facendo unha validación de restore cruzado nun cliente, atopei con que aparentemente esta premisa non se cumpría, e a restauración do controlfile mantiña o controlfile da BD como standby. Tras diferentes probas e consulta de información e notas Metalink, atopamos que o problema estaba a ser o bug 18455956, que en realidade só se presenta nun escenario no que a restauración do controlfile é executado sen conexión ó catálogo RMAN, que era xusto a proba que queriamos validar para facer unha apertura con resetlogs sen con elo impactar ó resto da configuración de Data Guard rexistrada no mesmo catálogo, evitando engadir unha nova encarnación “falsa” derivada desta proba. O obxectivo era derivar todas as tarefas de backup a unha BD standby, pero este problema fíxome plantexar a necesidade de ter que facer backups do controlfile primario (axudado, todo sexa dito, por un erro na documentación de certificación Data Guard de Oracle University onde se indicaba que os controlfiles non son intercambiables entre primary e standby).

Para verificar as posibilidades reais, creamos unha BD single instance nun servidor, e unha standby física noutro. Para simplificar as cousas, as dúas máquinas son en realidade un clúster con Grid Infrastructure, que comparten acceso a un filesystem ACFS montado en /acfs/desdata. A BD primaria ten por nome alberto e a standby bertodg (nomenclatura de Sergio a quen debo agradecer que montase este contorno nun tempo récord coa súa maxia usando gdbClone!). Antes de facer as probas de restauración, executamos en bertodg (standby) simplemente o comando backup database que fixo un backup á FRA configurada no mesmo filesystem. Polo tanto é un escenario sinxelo onde os backups das BDs están dispoñibles nos dous contornos sen necesidade de copiar datos previamente ou telos que recatalogar antes de restaurar.

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

Conectados á BD alberto e ó catálogo, nesta proba o script RMAN restaura explicitamente o controfile do backup feito previamente na BD bertodg. Pese a ser un standby controlfile, e sen especificar nada no comando RMAN, este é restaurado de xeito automático como un current controlfile válido para unha BD primaria.

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

Repetimos a proba anterior, pero esta vez sen conectar a catálogo RMAN. Funcionan a restauración e a recuperación, pero non é posible abrir a BD porque o controlfile non foi convertido durante o proceso e segue marcado como standby.

Verificamos que o controlfile non foi transformado en CURRENT durante a operación de RESTORE CONTROLFILE.

Bug 18455856

Parece lóxico que ó non contar co catálogo non sexa posible tomar a decisión de converter un controlfile a un tipo diferente do momento no que se fixo backup, xa que Oracle non ten a referencia do rol que desempeña a BD que restauramos dentro da configuración Data Guard. De feito, o comando RESTORE CONTROLFILE pode ser empregado, xa dende 11gR1, en 3 posibles variantes:

  • RESTORE CONTROLFILE. O controlfile é restaurado na BD á que estamos conectado e o seu tipo será determinado en función do rol asignado á BD no catálogo RMAN ó que estamos conectados. A BD sobre a que estamos traballando manterá o mesmo rol que tiña rexistrada no catálogo antes de iniciar a recuperación.
  • RESTORE PRIMARY CONTROLFILE. Con este comando forzamos que o controlfile que restauramos, sexa un backup dunha primary ou dunha standby, sexa configurado como BACKUP para o seu uso como BD primaria.
  • RESTORE STANDBY CONTROLFILE. O controlfile restaurado será configurado como STANDBY independentemente do rol que tivese a BD dende a que foi feito o backup.

Deste xeito, temos a opción de restaurar un controlfile de maneira automática en función do rol se conectamos a un repositorio RMAN, e temos a opción de facer unha conversión específica en caso de que vaiamos a cambiar o rol da BD ou que non poidamos determinalo de xeito automático ó non conectar a un catálogo. Se consultamos a nota Step by Step method to create Primary/Standby Database from Standby Backup (Doc ID 1604251.1), vemos que, como consecuencia da correción do bug 7553431, aparece un novo bug, o 18455956. Sen o correspondente parche aplicado, o comando RESTORE PRIMARY CONTROLFILE non fai a conversión precisa se non estamos empregando un catálogo RMAN cando recuperamos unha copia feita nunha standby. Se conectamos a catálogo RMAN (workaround proposto no bug), desaparece o problema.

No noso escenario, comprobamos que o parche 18455956 non está instalado, cun nivel de PSU de abril de 2017.

Ó ser así, podemos verificar que a restauración falla cando non empregamos catálogo, incluso especificando a opción PRIMARY, como podemos ver na seguinte proba:

Alternativas sen uso de catálogo

Agora que coñecemos tanto o problema como o seu alcance, podemos empregar diferentes alternativas como solución. A primeira pasa por recrear o controlfile dende a propia BD standby para a recuperación da BD primaria.

Pode resultar interesante saber que neste punto unha apertura en modo read only da BD funcionará e polo tanto teremos acceso ós datos.

Outra solución pasa pola apertura da BD recuperada, que será unha standby, como unha BD primaria, forzando un failover da mesma. Previamente para evitar erros eliminamos os standby logs e tamén deshabilitamos a flashback database, para evitar erros na apertura no intento de habilitar flashback database.

Resumo

Debemos empregar catálogo RMAN sempre para facer copias nun contorno Data Guard. Pese a elo, hai escenarios, como unha proba de restauración para validar os procedementos internos de backup, nas que nos pode interesar evitar o uso do catálogo para non interferir na configuración real de copias. En casos como este, debemos ser conscientes se estamos na versión 11.2.0.4 (non afecta a 11.2.0.3 ou anteriores) da existencia do bug 18455856 polo que teremos que optar, ben pola aplicación do correspondente parche, ben pola procedimentación do escenario tendo en conta a limitación na conversión a primary controlfile cando non nos conectamos ó catálogo RMAN.

Créditos

Ilustración: Alicia Constela

A %d blogueros les gusta esto: