Limitación en conversión automática de standby controlfile a primary controlfile

por | 1 Out 2017 | Oracle, portada, slider-post | 0 comentarios

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.

[oracle@nodo1 ~]$ rman target / catalog=usrcat/xxxxxx@rman
RMAN> run
{
  shutdown immediate;
  startup nomount;
  restore controlfile from '/acfs/desdata/bertodg/BERTODG/backupset/2017_09_29/o1_mf_ncsnf_TAG20170929T120630_dww6sbyk_.bkp';
  alter database mount;
  restore database;
  recover database noredo;
  alter database open resetlogs;
}2> 3> 4> 5> 6> 7> 8> 9> 10> 

database closed
database dismounted
Oracle instance shut down

connected to target database (not started)
Oracle instance started

Total System Global Area    4275781632 bytes

Fixed Size                     2260088 bytes
Variable Size               2449474440 bytes
Database Buffers            1811939328 bytes
Redo Buffers                  12107776 bytes

Starting restore at 29/09/2017 12:54:12
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=212 device type=DISK

channel ORA_DISK_1: restoring control file
channel ORA_DISK_1: restore complete, elapsed time: 00:00:01
output file name=/acfs/desdata/alberto/control01.ctl
Finished restore at 29/09/2017 12:54:13

database mounted
released channel: ORA_DISK_1

Starting restore at 29/09/2017 12:54:17
Starting implicit crosscheck backup at 29/09/2017 12:54:17
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=212 device type=DISK
Crosschecked 1 objects
Finished implicit crosscheck backup at 29/09/2017 12:54:18

Starting implicit crosscheck copy at 29/09/2017 12:54:18
using channel ORA_DISK_1
Crosschecked 2 objects
Finished implicit crosscheck copy at 29/09/2017 12:54:18

searching for all files in the recovery area
cataloging files...
cataloging done

List of Cataloged Files
=======================
File Name: /acfs/desdata/alberto/ALBERTO/archivelog/2017_09_28/o1_mf_1_34_06sfjc3k_.arc
File Name: /acfs/desdata/alberto/ALBERTO/archivelog/2017_09_28/o1_mf_1_1_dwsnj7rf_.arc
File Name: /acfs/desdata/alberto/ALBERTO/archivelog/2017_09_28/o1_mf_1_2_dwsnjx2d_.arc
File Name: /acfs/desdata/alberto/ALBERTO/archivelog/2017_09_28/o1_mf_1_3_dwsnlrhm_.arc
File Name: /acfs/desdata/alberto/ALBERTO/archivelog/2017_09_28/o1_mf_1_4_dwsnlvhy_.arc
File Name: /acfs/desdata/alberto/ALBERTO/archivelog/2017_09_28/o1_mf_1_5_dwt92r23_.arc
File Name: /acfs/desdata/alberto/ALBERTO/archivelog/2017_09_28/o1_mf_1_6_dwt92wjf_.arc
File Name: /acfs/desdata/alberto/ALBERTO/archivelog/2017_09_28/o1_mf_1_7_dwtrr0tq_.arc
File Name: /acfs/desdata/alberto/ALBERTO/archivelog/2017_09_29/o1_mf_1_8_dwvggf46_.arc
File Name: /acfs/desdata/alberto/ALBERTO/archivelog/2017_09_29/o1_mf_1_1_dww55lnk_.arc
File Name: /acfs/desdata/alberto/ALBERTO/archivelog/2017_09_29/o1_mf_1_2_dww55q9x_.arc
File Name: /acfs/desdata/alberto/ALBERTO/archivelog/2017_09_29/o1_mf_1_3_dww5rdbj_.arc
File Name: /acfs/desdata/alberto/ALBERTO/archivelog/2017_09_29/o1_mf_1_4_dww7z6wb_.arc
File Name: /acfs/desdata/alberto/ALBERTO/archivelog/2017_09_29/o1_mf_1_1_dww7z75j_.arc
File Name: /acfs/desdata/alberto/ALBERTO/archivelog/2017_09_29/o1_mf_1_2_dww7zbnc_.arc

using channel ORA_DISK_1

channel ORA_DISK_1: restoring datafile 00001
input datafile copy RECID=11 STAMP=955976061 file name=/acfs/desdata/.ACFS/snaps/bertodg/BERTODG/datafile/o1_mf_system_03sfjd9o_.dbf
destination for restore of datafile 00001: /acfs/desdata/.ACFS/snaps/alberto/ALBERTO/datafile/o1_mf_system_02sfjc33_.dbf
channel ORA_DISK_1: copied datafile copy of datafile 00001
output file name=/acfs/desdata/.ACFS/snaps/alberto/ALBERTO/datafile/o1_mf_system_02sfjc33_.dbf RECID=15 STAMP=955976062
channel ORA_DISK_1: restoring datafile 00002
input datafile copy RECID=12 STAMP=955976061 file name=/acfs/desdata/.ACFS/snaps/bertodg/BERTODG/datafile/o1_mf_sysaux_04sfjd9o_.dbf
destination for restore of datafile 00002: /acfs/desdata/.ACFS/snaps/alberto/ALBERTO/datafile/o1_mf_sysaux_03sfjc33_.dbf
channel ORA_DISK_1: copied datafile copy of datafile 00002
output file name=/acfs/desdata/.ACFS/snaps/alberto/ALBERTO/datafile/o1_mf_sysaux_03sfjc33_.dbf RECID=16 STAMP=955976065
channel ORA_DISK_1: restoring datafile 00003
input datafile copy RECID=13 STAMP=955976061 file name=/acfs/desdata/.ACFS/snaps/bertodg/BERTODG/datafile/o1_mf_undotbs1_05sfjd9o_.dbf
destination for restore of datafile 00003: /acfs/desdata/.ACFS/snaps/alberto/ALBERTO/datafile/o1_mf_undotbs1_04sfjc33_.dbf
channel ORA_DISK_1: copied datafile copy of datafile 00003
output file name=/acfs/desdata/.ACFS/snaps/alberto/ALBERTO/datafile/o1_mf_undotbs1_04sfjc33_.dbf RECID=17 STAMP=955976068
channel ORA_DISK_1: restoring datafile 00004
input datafile copy RECID=14 STAMP=955976061 file name=/acfs/desdata/.ACFS/snaps/bertodg/BERTODG/datafile/o1_mf_users_06sfjd9r_.dbf
destination for restore of datafile 00004: /acfs/desdata/.ACFS/snaps/alberto/ALBERTO/datafile/o1_mf_users_05sfjc3i_.dbf
channel ORA_DISK_1: copied datafile copy of datafile 00004
output file name=/acfs/desdata/.ACFS/snaps/alberto/ALBERTO/datafile/o1_mf_users_05sfjc3i_.dbf RECID=18 STAMP=955976068

datafile 1 switched to datafile copy
input datafile copy RECID=19 STAMP=955976069 file name=/acfs/desdata/.ACFS/snaps/alberto/ALBERTO/datafile/o1_mf_system_02sfjc33_.dbf
datafile 2 switched to datafile copy
input datafile copy RECID=20 STAMP=955976069 file name=/acfs/desdata/.ACFS/snaps/alberto/ALBERTO/datafile/o1_mf_sysaux_03sfjc33_.dbf
datafile 3 switched to datafile copy
input datafile copy RECID=21 STAMP=955976069 file name=/acfs/desdata/.ACFS/snaps/alberto/ALBERTO/datafile/o1_mf_undotbs1_04sfjc33_.dbf
datafile 4 switched to datafile copy
input datafile copy RECID=22 STAMP=955976069 file name=/acfs/desdata/.ACFS/snaps/alberto/ALBERTO/datafile/o1_mf_users_05sfjc3i_.dbf
Finished restore at 29/09/2017 12:54:29

Starting recover at 29/09/2017 12:54:30
using channel ORA_DISK_1
renamed tempfile 1 to /acfs/desdata/.ACFS/snaps/alberto/ALBERTO/datafile/o1_mf_temp_dwsmc1kp_.tmp in control file

Finished recover at 29/09/2017 12:54:31

database opened
new incarnation of database registered in recovery catalog
starting full resync of recovery catalog
full resync complete
starting full resync of recovery catalog
full resync complete

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.

[oracle@nodo1 ~]$ rman target /

Recovery Manager: Release 11.2.0.4.0 - Production on Sun Oct 1 15:57:04 2017

Copyright (c) 1982, 2011, Oracle and/or its affiliates.  All rights reserved.

connected to target database: ALBERTO (DBID=2724215542)

RMAN> run
{
  shutdown immediate;
  startup nomount;
  restore controlfile from '/acfs/desdata/bertodg/BERTODG/backupset/2017_09_29/o1_mf_ncsnf_TAG20170929T120630_dww6sbyk_.bkp';
  alter database mount;
  restore database;
  recover database noredo;
  alter database open resetlogs;
}2> 3> 4> 5> 6> 7> 8> 9> 10> 

using target database control file instead of recovery catalog
database closed
database dismounted
Oracle instance shut down

connected to target database (not started)
Oracle instance started

Total System Global Area    4275781632 bytes

Fixed Size                     2260088 bytes
Variable Size               2449474440 bytes
Database Buffers            1811939328 bytes
Redo Buffers                  12107776 bytes

Starting restore at 01/10/2017 15:57:24
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=212 device type=DISK

channel ORA_DISK_1: restoring control file
channel ORA_DISK_1: restore complete, elapsed time: 00:00:01
output file name=/acfs/desdata/alberto/control01.ctl
Finished restore at 01/10/2017 15:57:25

database mounted
released channel: ORA_DISK_1

Starting restore at 01/10/2017 15:57:30
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=212 device type=DISK

skipping datafile 1; already restored to file /acfs/desdata/.ACFS/snaps/bertodg/BERTODG/datafile/o1_mf_system_03sfjd9o_.dbf
skipping datafile 2; already restored to file /acfs/desdata/.ACFS/snaps/bertodg/BERTODG/datafile/o1_mf_sysaux_04sfjd9o_.dbf
skipping datafile 3; already restored to file /acfs/desdata/.ACFS/snaps/bertodg/BERTODG/datafile/o1_mf_undotbs1_05sfjd9o_.dbf
skipping datafile 4; already restored to file /acfs/desdata/.ACFS/snaps/bertodg/BERTODG/datafile/o1_mf_users_06sfjd9r_.dbf
restore not done; all files read only, offline, or already restored
Finished restore at 01/10/2017 15:57:31

Starting recover at 01/10/2017 15:57:31
using channel ORA_DISK_1

Finished recover at 01/10/2017 15:57:32

RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of alter db command at 10/01/2017 15:57:33
ORA-01666: control file is for a standby database

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

SQL> select controlfile_type from v$database;

CONTROL
-------
STANDBY

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.

[oracle@nodo1 ~]$ $ORACLE_HOME/OPatch/opatch lsinventory | grep "Patch Set Update"
Patch description:  "Database Patch Set Update : 11.2.0.4.170418 (24732075)"
Sub-patch  24006111; "Database Patch Set Update : 11.2.0.4.161018 (24006111)"
Sub-patch  23054359; "Database Patch Set Update : 11.2.0.4.160719 (23054359)"
Sub-patch  22502456; "Database Patch Set Update : 11.2.0.4.160419 (22502456)"
Sub-patch  21948347; "Database Patch Set Update : 11.2.0.4.160119 (21948347)"
Sub-patch  21352635; "Database Patch Set Update : 11.2.0.4.8 (21352635)"
Sub-patch  20760982; "Database Patch Set Update : 11.2.0.4.7 (20760982)"
Sub-patch  20299013; "Database Patch Set Update : 11.2.0.4.6 (20299013)"
Sub-patch  19769489; "Database Patch Set Update : 11.2.0.4.5 (19769489)"
Sub-patch  19121551; "Database Patch Set Update : 11.2.0.4.4 (19121551)"
Sub-patch  18522509; "Database Patch Set Update : 11.2.0.4.3 (18522509)"
Sub-patch  18031668; "Database Patch Set Update : 11.2.0.4.2 (18031668)"
Sub-patch  17478514; "Database Patch Set Update : 11.2.0.4.1 (17478514)"

[oracle@nodo1 ~]$ $ORACLE_HOME/OPatch/opatch lsinventory | grep 18455956
[oracle@nodo1 ~]$

Ó 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:

[oracle@nodo1 ~]$ rman target /
 
Recovery Manager: Release 11.2.0.4.0 - Production on Sun Oct 1 15:58:16 2017
 
Copyright (c) 1982, 2011, Oracle and/or its affiliates.  All rights reserved.
 
connected to target database: ALBERTO (DBID=2724215542)

RMAN> run
{
  shutdown immediate;
  startup nomount;
  restore primary controlfile from '/acfs/desdata/bertodg/BERTODG/backupset/2017_09_29/o1_mf_ncsnf_TAG20170929T120630_dww6sbyk_.bkp';
  alter database mount;
  restore database;
  recover database noredo;
  alter database open resetlogs;
}2> 3> 4> 5> 6> 7> 8> 9> 10> 

database dismounted
Oracle instance shut down

connected to target database (not started)
Oracle instance started

Total System Global Area    4275781632 bytes

Fixed Size                     2260088 bytes
Variable Size               2449474440 bytes
Database Buffers            1811939328 bytes
Redo Buffers                  12107776 bytes

Starting restore at 01/10/2017 15:58:17
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=212 device type=DISK

channel ORA_DISK_1: restoring control file
channel ORA_DISK_1: restore complete, elapsed time: 00:00:01
output file name=/acfs/desdata/alberto/control01.ctl
Finished restore at 01/10/2017 15:58:19

database mounted
released channel: ORA_DISK_1

Starting restore at 01/10/2017 15:58:23
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=212 device type=DISK

skipping datafile 1; already restored to file /acfs/desdata/.ACFS/snaps/bertodg/BERTODG/datafile/o1_mf_system_03sfjd9o_.dbf
skipping datafile 2; already restored to file /acfs/desdata/.ACFS/snaps/bertodg/BERTODG/datafile/o1_mf_sysaux_04sfjd9o_.dbf
skipping datafile 3; already restored to file /acfs/desdata/.ACFS/snaps/bertodg/BERTODG/datafile/o1_mf_undotbs1_05sfjd9o_.dbf
skipping datafile 4; already restored to file /acfs/desdata/.ACFS/snaps/bertodg/BERTODG/datafile/o1_mf_users_06sfjd9r_.dbf
restore not done; all files read only, offline, or already restored
Finished restore at 01/10/2017 15:58:24

Starting recover at 01/10/2017 15:58:24
using channel ORA_DISK_1

Finished recover at 01/10/2017 15:58:25

RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of alter db command at 10/01/2017 15:58:25
ORA-01666: control file is for a standby database

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.

SQL> alter database open read only;

Database altered.

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.

SQL> select * from v$logfile;

    GROUP# STATUS  TYPE    MEMBER									    IS_
---------- ------- ------- -------------------------------------------------------------------------------- ---
	 3	   ONLINE  /acfs/desdata/bertodg/BERTODG/onlinelog/o1_mf_3_dwsnjzp0_.log		    NO
	 2	   ONLINE  /acfs/desdata/bertodg/BERTODG/onlinelog/o1_mf_2_dwsnjzkj_.log		    NO
	 1	   ONLINE  /acfs/desdata/bertodg/BERTODG/onlinelog/o1_mf_1_dwsnjzdr_.log		    NO
	 4	   STANDBY /acfs/desdata/bertodg/BERTODG/onlinelog/o1_mf_4_dww5rdg9_.log		    NO
	 5	   STANDBY /acfs/desdata/bertodg/BERTODG/onlinelog/o1_mf_5_dww5rdgy_.log		    NO
	 6	   STANDBY /acfs/desdata/bertodg/BERTODG/onlinelog/o1_mf_6_dww5rdg2_.log		    NO


SQL> alter database clear logfile group 4;

Database altered.

SQL> alter database clear logfile group 5;

Database altered.

SQL> alter database clear logfile group 6;

Database altered.

SQL> alter database open;
alter database open
*
ERROR at line 1:
ORA-38760: This database instance failed to turn on flashback database

SQL> alter database flashback off;

Database altered.

SQL> alter database open;

Database altered.

SQL> alter database flashback on;

Database altered.

SQL> select controlfile_type from v$database;

CONTROL
-------
CURRENT

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

Enviar un comentario

O teu correo electrónico non se publicará. Os campos obrigatorios están marcados con *

nine − 1 =