Oracle Database 12c – Resolução de Redo Gap (Part II)

Por Joel Perez , Mahir M. Quluzade (OCP) & Carlos H. Y. Furushima
Postado em Dezembro 2014

Revisado por Marcelo Pivovar - Solution Architect

Este texto é a segunda parte do artigo "Oracle Database 12c – Resolução de Redo Gap", por isso é importante que o leitor tenha o pleno entendimento da primeira parte do artigo.

Conforme abordado na primeira parte do artigo, quando o processo de “media recovery” não consegue abrir o archived log (no standby database) então é iniciado um mecanismo de busca por archivelog (fetching gap sequence), afim de satisfazer a relação de sincronismo entre database primário e standby database, esta busca por archivelog (fetching gap sequence), envolve o processo RFS que solicita ao database primário o(s) archivelog(s) necessários para eliminar o "gap sequence". Se encontrado o processo RFS permite que o archivelogs seja refeito ou sobrescrevido, uma vez que o processo ARCH no database primário reenvia as entradas de redo novamente.
Nesta segunda parte, temos um cenário onde existe uma indisponibilidade da infra-estrutura de rede (sem comunicação entre database primário e standby database), ocorrendo um archive gap no standby database. Antes que a conexão entre o database primário e standby database seja reestabelecida, os archivelogs não enviados (not shipped archived redo logs) são removidos ou corrompidos no database primário.

O que é Archive Gap?
É um intervalo onde houve ocorrência de falta de entradas de redo (missing redo) no standby database, gerando um dessincronizarão entre database primário e standby database, em decorrência disto o Apply Services (serviço de aplicação), no standby database está impedido de prosseguir com suas funções (aplicar entradas de redo geradas no database primário). Isso normalmente acontece quando o standby database é incapaz de receber as entradas de redo geradas no database primário ou as entradas de redo não estejam disponíveis standby database.Algumas possíveis causas são:

  • Indisponibilidade ou problemas de network bandwidth na infra-estrutura de rede entre database primário e standby database (Cabeamento estrutura entre database primário e standby database).
  • Serviço de transporte de redo (transport service) parado ou com erros de configuração (Apontamentos entre database primário e standby database).
  • Standby database em shutdown.
  • Problemas de I/O no standby database.

Abordaremos dois possíveis casos sobre este cenário citado acima:

  • Caso 1) Archivelogs não enviados (not shipped archived redo logs) foram backupeados via RMAN ou movidos manualmente para outro diretório (consequentemente removidos do diretório de origem).
  • Caso 2) Archivelogs não enviados (not shipped archived redo logs) foram removidos ou corrompidos no database primário. (NÃO existem backup ou copias dos archivelogs não enviados em outro diretório, como ocorre no caso 1).

Demonstração 3:
No caso 1, os archivelogs necessários para correção do archive gap gerado, não foram perdidos, foram transformados em backupset via utilitário RMAN, isso significa que os archivelogs não estão localizados onde foram originalmente gerados, isso faz com que o Dataguard perca o controle sobre a localização dos archivelogs, impossibilitando-o de resolver o gap, neste caso é necessário restaurar os archivelogs faltantes (após restaurado o dataguard automaticamente resolve do GAP). No caso de movimentação manual para outro diretório, basta o DBA realocar os archivelogs movidos para sua localização original, para que o dataguard automaticamente resolve o GAP.

  • No standby database existe um archive gap, a “low sequence” do archive gap é 265 e a “high sequence” do archive gap é 267 (Isso significa que o standby database ficar sincronizados é necessário os archivelogs 265, 266 e 267).
[oracle@oel62-stbdb-12c ~]$ export  ORACLE_SID=stbcdb
   [oracle@oel62-stbdb-12c ~]$ sqlplus / as  sysdba

SQL*Plus: Release 12.1.0.1.0 Production on  Thu Aug 1 17:02:23 2014

Copyright (c) 1982, 2013, Oracle.  All rights reserved.

Connected to:
   Oracle Database 12c Enterprise Edition  Release 12.1.0.1.0 - 64bit Production
   With the Partitioning, OLAP, Advanced  Analytics and Real Application Testing options

SQL> select max(sequence#) from  v$archived_log;

MAX(SEQUENCE#)
--------------------------
268

SQL> select max(sequence#) from  v$archived_log where applied='YES';

MAX(SEQUENCE#)
--------------------------
264

SQL> select * from v$archive_gap;

THREAD#     LOW_SEQUENCE#    HIGH_SEQUENCE#    CON_ID
----------  ---------------  ----------------  ----------
1           265              267               1



Alert log do standby database

   …
   Media Recovery Waiting for thread 1 sequence  265
   Fetching gap sequence in thread 1, gap  sequence 265-267
   Thu Aug 01 17:03:19 2014
   FAL[client]: Failed to request gap sequence
   GAP -  thread 1 sequence 265-267
   DBID  2485119180 branch 820252236
   FAL[client]: All defined FAL servers have  been attempted.
   ...

O dataguard tentou resolver o gap em todos os FAL servers, porem o gap não foi resolvido. Pois os archivelogs não estão no local de origem. (Foram backupeados e removidos ou simplesmente movidos para outro FileSystem).

  • Restaurando os archivedlogs do backup RMAN.
[oracle@oel62-prmdb-12c ~]$ export  ORACLE_SID=prmcdb
   [oracle@oel62-prmdb-12c ~]$ rman target / 

Recovery Manager: Release 12.1.0.1.0 -  Production on Thu Aug 1 17:08:04 2014
   Copyright (c) 1982, 2013, Oracle and/or its  affiliates.  All rights reserved.

connected to target database: PRMCDB  (DBID=2485119180)

RMAN> list backup of archivelog from  logseq 265 until logseq 267;

using target database control file instead of  recovery catalog

List of Backup Sets
===================

BS Key  Size       Device Type Elapsed Time  Completion Time
------- ---------- ----------- ------------  ---------------
19      18.19M     DISK        00:00:02      01-AUG-13      
BP Key:  19   Status:  AVAILABLE  Compressed: NO  Tag: TAG20140801T165419
Piece Name: 
/u01/app/oracle/fast_recovery_area/PRMCDB/backupset/2014_08_01/o1_mf_annnn_TAG20140801T165419_8znm3dc0_.bkp

List  of Archived Logs in backup set 19
Thrd Seq     Low SCN    Low Time  Next SCN   Next Time
---- ------- ---------- --------- ---------- ---------
1    265     2303068    01-AUG-13 2303129    01-AUG-13
1    266     2303129    01-AUG-13 2303136    01-AUG-13
1    267     2303136    01-AUG-13 2303203    01-AUG-13

RMAN> restore archivelog from logseq 265 until logseq 267;

Starting restore at 01-AUG-13
   allocated channel: ORA_DISK_1
   channel ORA_DISK_1: SID=7 device type=DISK

channel ORA_DISK_1: starting archived log  restore to default destination
   channel ORA_DISK_1: restoring archived log
   archived log thread=1 sequence=265
   channel ORA_DISK_1: restoring archived log
   archived log thread=1 sequence=266
   channel ORA_DISK_1: restoring archived log
   archived log thread=1 sequence=267
   channel ORA_DISK_1: reading from backup piece  /u01/app/oracle/fast_recovery_area/PRMCDB/backupset/
2014_08_01/o1_mf_annnn_TAG20140801T165419_8znm3dc0_.bkp
   channel ORA_DISK_1: piece  handle=/u01/app/oracle/fast_recovery_area/PRMCDB/backupset/2014_08_01/
o1_mf_annnn_TAG20140801T165419_8znm3dc0_.bkp  tag=TAG20140801T165419
   channel ORA_DISK_1: restored backup piece 1
   channel ORA_DISK_1: restore complete, elapsed  time: 00:00:03
   Finished restore at 01-AUG-13

Alert log do standby database:

…
   RFS[8]: Opened log for thread 1 sequence 266  dbid 2485119180 branch 820252236
   RFS[6]: Opened log for thread 1 sequence 267  dbid 2485119180 branch 820252236
   Thu Aug 01 17:09:33 2014
   Archived Log entry 20 added for thread 1  sequence 266rlc 820252236 ID 0x0  dest 2:
   Thu Aug 01 17:09:33 2014
   RFS[9]: Assigned to RFS process (PID:4722)
   RFS[9]: Opened log for thread 1 sequence 265  dbid 2485119180 branch 820252236
   Thu Aug 01 17:09:34 2014
   Archived Log entry 21 added for thread 1  sequence 267rlc 820252236 ID 0x0  dest 2:
   Thu Aug 01 17:09:34 2014
   Archived Log entry 22 added for thread 1  sequence 265rlc 820252236 ID 0x0  dest 2:
   Thu Aug 01 17:09:35 2014
   Media Recovery Log  /u01/app/oracle/fast_recovery_area/STBCDB/archivelog/2014_08_01/o1_mf_1_265_8znmzxnv_.arc
   Thu Aug 01 17:09:35 2014
   Media Recovery Log  /u01/app/oracle/fast_recovery_area/STBCDB/archivelog/2014_08_01/o1_mf_1_266_8znmzx8w_.arc
   Thu Aug 01 17:09:36 2014
   Media Recovery Log  /u01/app/oracle/fast_recovery_area/STBCDB/archivelog/2014_08_01/o1_mf_1_267_8znmzxgw_.arc
   Thu Aug 01 17:09:37 2014
   Media Recovery Log  /u01/app/oracle/fast_recovery_area/STBCDB/archivelog/2014_08_01/o1_mf_1_268_8znm76lb_.arc
   Media Recovery Waiting for thread 1 sequence  269
   …

Para verificar se há archive gap no standby database, basta consultar a view v$archive_gap.

[oracle@oel62-stbdb-12c Desktop]$ export  ORACLE_SID=stbcdb
   [oracle@oel62-stbdb-12c ~]$ sqlplus / as sysdba

SQL*Plus: Release 12.1.0.1.0 Production on  Thu Aug 1 17:12:20 2014
   Copyright (c) 1982, 2013, Oracle.  All rights reserved.

Connected to:
   Oracle Database 12c Enterprise Edition  Release 12.1.0.1.0 - 64bit Production
   With the Partitioning, OLAP, Advanced  Analytics and Real Application Testing options

SQL> select * from v$archive_gap;

norowsselected

Veja que o próprio Data Guard resolveu automaticamente o Archive Gap, após a restauração dos archived logs que estavam em backupeados em forma de backupset.

No segundo caso (caso 2), onde não há os archivelogs materializados em backupset (archivelogs backupeados), é possível usar 2 métodos para resolver o gap:

  • Backup incremental com RMAN para execução de Roll-Forward.
  • Restore/Recover de arquivos de banco de dados remotamente com RMAN para execução de Roll-Forward.

Obs.: É importante ressaltar que os 2 métodos citados é validos para um Standby Database Físico (Physical standby database).

O que é Roll-Forward?
É um processo que consistem em aplicar alterações gerados por entradas de redo aos datafiles do database com o objetivo de avançar os dados em função de uma cronologia temporal, ou seja, as entradas de redo são aplicadas sequencialmente até que o database atinja um determinando SCN, sequence ou tempo.

O primeiro método "Backup incremental com RMAN para execução de Roll-Forward" é possível ser aplicado a partir das versões 10g, obviamente é possível usar esta método nas versões 12c. Contudo, o segundo método "Restore/Recover de arquivos de banco de dados remotamente com RMAN para execução de Roll-Forward" é um novo recurso (new feature) do Oracle Database 12c.

Demonstração 4:

Backup incremental com RMAN para execução de Roll-Forward.

Detectado um novo archive gap no standby database:

[oracle@oel62-stbdb-12c ~]$ export  ORACLE_SID=stbcdb
 [oracle@oel62-stbdb-12c ~]$ sqlplus / as  sysdba

SQL*Plus: Release 12.1.0.1.0 Production on  Fri Aug 2 12:33:24 2014

Copyright (c) 1982, 2013, Oracle.  All rights reserved.

Connected to:
   Oracle Database 12c Enterprise Edition  Release 12.1.0.1.0 - 64bit Production
   With the Partitioning, OLAP, Advanced  Analytics and Real Application Testing options

SQL> select * from v$archive_gap;

THREAD#     LOW_SEQUENCE#     HIGH_SEQUENCE#     CON_ID
---------   ----------------  -----------------  ------------
1           290               296                1

SQL> select max(sequence#)  from v$archived_log where applied = 'YES';

MAX(SEQUENCE#)
--------------------------
289

SQL> select max(sequence#)  from v$archived_log;

MAX(SEQUENCE#)
---------------------------
299

 

  • Pare o redo apply process (processo de aplicação de redo) e verifique o SCN atual (current SCN) no standby database:

 

[oracle@oel62-stbdb-12c ~]$ export  ORACLE_SID=stbcdb
   [oracle@oel62-stbdb-12c ~]$ sqlplus / as  sysdba

SQL*Plus: Release 12.1.0.1.0 Production on  Fri Aug 2 13:04:14 2014
   Copyright (c) 1982, 2013, Oracle.  All rights reserved.

Connected to:
   Oracle Database 12c Enterprise Edition  Release 12.1.0.1.0 - 64bit Production
   With the Partitioning, OLAP, Advanced  Analytics and Real Application Testing options

SQL> alter database recover managed  standby database cancel;

Database altered.

SQL> select current_scnfrom  v$database;

CURRENT_SCN
-------------------------
2318144

  •  Criação de um backup incremental com RMAN a partir do SCN atual (current SCN):
[oracle@oel62-prmdb-12c ~]$ export  ORACLE_SID=prmcdb
 [oracle@oel62-prmdb-12c ~]$ rman

Recovery Manager: Release 12.1.0.1.0 -  Production on Fri Aug 2 13:15:36 2014

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

RMAN> connect target "sys as  sysbackup";

target database Password: 
   connected to target database: PRMCDB  (DBID=2485119180)

RMAN> BACKUP INCREMENTAL FROM SCN 2318144 DATABASE  FORMAT '/tmp/backup/ForStandby_%U' tag 'FORSTANDBY';

Starting backup at 02-AUG-13
   using target database control file instead of  recovery catalog
   allocated channel: ORA_DISK_1
   channel ORA_DISK_1: SID=42 device type=DISK
   channel ORA_DISK_1: starting full datafile  backup set
   channel ORA_DISK_1: specifying datafile(s) in  backup set
   input datafile file number=00003  name=/u01/app/oracle/oradata/prmcdb/sysaux01.dbf
   input datafile file number=00001  name=/u01/app/oracle/oradata/prmcdb/system01.dbf
   input datafile file number=00004  name=/u01/app/oracle/oradata/prmcdb/undotbs01.dbf
   input datafile file number=00006  name=/u01/app/oracle/oradata/prmcdb/users01.dbf
   channel ORA_DISK_1: starting piece 1 at  02-AUG-13
   channel ORA_DISK_1: finished piece 1 at  02-AUG-13
   piece  handle=/tmp/backup/ForStandby_2bog9o32_1_1 tag=FORSTANDBY comment=NONE
   channel ORA_DISK_1: backup set complete,  elapsed time: 00:00:03
   channel ORA_DISK_1: starting full datafile  backup set
   channel ORA_DISK_1: specifying datafile(s) in  backup set
   input datafile file number=00009  name=/u01/app/oracle/oradata/prmcdb/prmdb01/sysaux01.dbf
   skipping datafile 00009 because it has not  changed
   input datafile file number=00011  name=/u01/app/oracle/oradata/prmcdb/prmdb01/example01.dbf
   skipping datafile 00011 because it has not  changed
   input datafile file number=00008  name=/u01/app/oracle/oradata/prmcdb/prmdb01/system01.dbf
   skipping datafile 00008 because it has not  changed
   input datafile file number=00010  name=/u01/app/oracle/oradata/prmcdb/prmdb01/SAMPLE_SCHEMA_users01.dbf
   skipping datafile 00010 because it has not  changed
   channel ORA_DISK_1: backup cancelled because  all files were skipped
   channel ORA_DISK_1: starting full datafile  backup set
   channel ORA_DISK_1: specifying datafile(s) in  backup set
   input datafile file number=00013  name=/u01/app/oracle/oradata/prmcdb/prmdb02/sysaux01.dbf
   skipping datafile 00013 because it has not  changed
   input datafile file number=00012  name=/u01/app/oracle/oradata/prmcdb/prmdb02/system01.dbf
   skipping datafile 00012 because it has not  changed
   channel ORA_DISK_1: backup cancelled because  all files were skipped
   channel ORA_DISK_1: starting full datafile  backup set
   channel ORA_DISK_1: specifying datafile(s) in  backup set
   input datafile file number=00007  name=/u01/app/oracle/oradata/prmcdb/pdbseed/sysaux01.dbf
   skipping datafile 00007 because it has not  changed
   input datafile file number=00005  name=/u01/app/oracle/oradata/prmcdb/pdbseed/system01.dbf
   skipping datafile 00005 because it has not  changed
   channel ORA_DISK_1: backup cancelled because  all files were skipped
   channel ORA_DISK_1: starting full datafile  backup set
   channel ORA_DISK_1: specifying datafile(s) in  backup set
   including current control file in backup set
   channel ORA_DISK_1: starting piece 1 at  02-AUG-13
   channel ORA_DISK_1: finished piece 1 at  02-AUG-13
   piece  handle=/tmp/backup/ForStandby_2fog9o37_1_1 tag=FORSTANDBY comment=NONE
   channel ORA_DISK_1: backup set complete,  elapsed time: 00:00:01
   Finished backup at 02-AUG-13

RMAN>

O backup gerado conterá todas as modificações a partir do último backup Full ou incremental até o SCN atual (current SCN)

  • Backup do controlfile para standby database:
RMAN> backup current controlfile for  standby format '/tmp/backup/forStandby.ctl';

Starting backup at 02-AUG-13
   using channel ORA_DISK_1
   channel ORA_DISK_1: starting full datafile  backup set
   channel ORA_DISK_1: specifying datafile(s) in  backup set
   including standby control file in backup set
   channel ORA_DISK_1: starting piece 1 at  02-AUG-13
   channel ORA_DISK_1: finished piece 1 at  02-AUG-13
   piece handle=/tmp/backup/forStandby.ctl  tag=TAG20140802T133754 comment=NONE
   channel ORA_DISK_1: backup set complete,  elapsed time: 00:00:01
 Finished backup at 02-AUG-13

  • Transferência de todos os backup pieces gerados no database primário para o standby database:
[oracle@oel62-prmdb-12c backup]$ ls -l
   total 42768
   -rw-r----- 1 oracle oinstall  6635520 Aug   2 13:19 ForStandby_2bog9o32_1_1
   -rw-r----- 1 oracle oinstall 18579456  Aug  2 13:19 ForStandby_2fog9o37_1_1
   -rw-r----- 1 oracle oinstall 18579456  Aug  2 13:37 forStandby.ctl
   [oracle@oel62-prmdb-12c backup]$ scp *  oracle@192.168.56.196:/tmp/BackupFromPrimary
   oracle@192.168.56.196's password: 
   ForStandby_2bog9o32_1_1                     100% 6480KB   6.3MB/s    00:01    
   ForStandby_2fog9o37_1_1                      100%   18MB   17.7MB/s   00:01    
   forStandby.ctl100%   18MB   17.7MB/s   00:01    
   [oracle@oel62-prmdb-12c backup]$ pwd
 /tmp/backup

No standby side:

[oracle@oel62-stbdb-12c BackupFromPrimary]$  ls -l
   total 42768
   -rw-r----- 1 oracle oinstall  6635520 Aug   2 13:40 ForStandby_2bog9o32_1_1
   -rw-r----- 1 oracle oinstall 18579456  Aug  2 13:40 ForStandby_2fog9o37_1_1
   -rw-r----- 1 oracle oinstall 18579456  Aug  2 13:40 forStandby.ctl
   [oracle@oel62-stbdb-12c BackupFromPrimary]$  pwd
   /tmp/BackupFromPrimary

  • Restaurando o standby control file:
[oracle@oel62-stbdb-12c ~]$ export  ORACLE_SID=stbcdb
 [oracle@oel62-stbdb-12c ~]$ rman

Recovery Manager: Release 12.1.0.1.0 -  Production on Fri Aug 2 13:44:10 2014
 Copyright (c) 1982, 2013, Oracle and/or its  affiliates.  All rights reserved.

RMAN> connect target "sys as  sysbackup";

target database Password: 
   connected to target database: PRMCDB (not  mounted)

RMAN> shutdown immediate;

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

RMAN> startup nomount;

connected to target database (not started)
   Oracle instance started

Total System Global Area     801701888 bytes

Fixed Size                   2293496 bytes
Variable Size                603980040 bytes
Database Buffers             192937984 bytes
Redo Buffers                 2490368 bytes

RMAN> restore standby controlfile from  '/tmp/BackupFromPrimary/forStandby.ctl';

Starting restore at 02-AUG-13
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=21 device type=DISK

channel ORA_DISK_1: restoring control file
channel ORA_DISK_1: restore complete, elapsed  time: 00:00:01
output file  name=/u01/app/oracle/oradata/stbcdb/control01.ctl
Finished restore at 02-AUG-13

RMAN> alter database mount;

Statement processed
released channel: ORA_DISK_1

  • Catalogando os novos backup piecesno standby database:
RMAN> catalog start with '/tmp/BackupFromPrimary';

Starting implicit crosscheck backup at  02-AUG-13
   allocated channel: ORA_DISK_1
   channel ORA_DISK_1: SID=30 device type=DISK
 Finished implicit crosscheck backup at  02-AUG-13

Starting implicit crosscheck copy at  02-AUG-13
   using channel ORA_DISK_1
   Crosschecked 6 objects
   Finished implicit crosscheck copy at  02-AUG-13

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

List of Cataloged Files
   =======================
   File Name: /u01/app/oracle/fast_recovery_area/STBCDB/archivelog/2014_08_02/o1_mf_1_290_8zpqtcwk_.arc
   File Name:  /u01/app/oracle/fast_recovery_area/STBCDB/archivelog/2014_08_02/o1_mf_1_291_8zpr3x6l_.arc
   …
   searching for all files that match the  pattern /tmp/BackupFromPrimary

List of Files Unknown to the Database
   =====================================
   File Name:  /tmp/BackupFromPrimary/ForStandby_2bog9o32_1_1
   File Name:  /tmp/BackupFromPrimary/ForStandby_2fog9o37_1_1
   File Name:  /tmp/BackupFromPrimary/forStandby.ctl

Do you really want to catalog the above files  (enter YES or NO)? YES
   cataloging files...
   cataloging done

List of Cataloged Files
   =======================
   File Name:  /tmp/BackupFromPrimary/ForStandby_2bog9o32_1_1
   File Name:  /tmp/BackupFromPrimary/ForStandby_2fog9o37_1_1
   File Name:  /tmp/BackupFromPrimary/forStandby.ctl

 

  • Recover database usando backup incremental :
RMAN> recover database noredo;

Starting recover at 02-AUG-13
   using channel ORA_DISK_1
   channel ORA_DISK_1: starting incremental  datafile backup set restore
   channel ORA_DISK_1: specifying datafile(s) to  restore from backup set
   destination for restore of datafile 00001:  /u01/app/oracle/oradata/stbcdb/system01.dbf
   destination for restore of datafile 00003:  /u01/app/oracle/oradata/stbcdb/sysaux01.dbf
   destination for restore of datafile 00004:  /u01/app/oracle/oradata/stbcdb/undotbs01.dbf
   destination for restore of datafile 00006:  /u01/app/oracle/oradata/stbcdb/users01.dbf
   channel ORA_DISK_1: reading from backup piece  /tmp/BackupFromPrimary/ForStandby_2bog9o32_1_1
   channel ORA_DISK_1: piece  handle=/tmp/BackupFromPrimary/ForStandby_2bog9o32_1_1 tag=FORSTANDBY
   channel ORA_DISK_1: restored backup piece 1
   channel ORA_DISK_1: restore complete, elapsed  time: 00:01:05

Finished recover at 02-AUG-13

 

  • Iniciando redo apply process(processo de aplicação de redo):
RMAN> alter database recover managed standby  database disconnect from session;

Statement processed

RMAN> select * from v$archive_gap;

no rows selected

RMAN>

 

Demonstração 5:
Restore/Recover de arquivos de banco de dados remotamente com RMAN para execução de Roll-Forward.

Este método é possível somente no Oracle Database 12c. (A partir do 12.1.0.1)

Detectado um novo archive gap no standby database:

[oracle@oel62-stbdb-12c ~]$ export  ORACLE_SID=stbcdb
 [oracle@oel62-stbdb-12c ~]$ sqlplus / as  sysdba

SQL*Plus: Release 12.1.0.1.0 Production on  Thu Aug 1 17:24:32 2014
   Copyright (c) 1982, 2013, Oracle.  All rights reserved.

Connected to:
   Oracle Database 12c Enterprise Edition  Release 12.1.0.1.0 - 64bit Production
   With the Partitioning, OLAP, Advanced  Analytics and Real Application Testing options

SQL>   select max(sequence#)  from  v$archived_log;

MAX(SEQUENCE#)
------------------------
277

SQL> select max(sequence#)  from v$archived_log where applied ='YES';

MAX(SEQUENCE#)
-------------------------
271
   
SQL> select * from v$archive_gap;

THREAD#   LOW_SEQUENCE#  HIGH_SEQUENCE#  CON_ID
--------  -------------  --------------  ------
      1             272             275       1

Não existe no database primário, qualquer backup de archivelogs:

[oracle@oel62-prmdb-12c ~]$ export  ORACLE_SID=prmcdb
   [oracle@oel62-prmdb-12c ~]$ rman target / 

Recovery Manager: Release 12.1.0.1.0 -  Production on Thu Aug 1 17:26:30 2014
   Copyright (c) 1982, 2013, Oracle and/or its  affiliates.  All rights reserved.

connected to target database: PRMCDB  (DBID=2485119180)

RMAN> list backup of archivelog from  logseq 272 until logseq 275;

using target database control file instead of  recovery catalog
   specification does not match any backup in  the repository

RMAN> list backup of archivelog all;

specification does not match any backup in  the repository

 

  • Parando o Redo Apply e executando shutdown no standby database:
[oracle@oel62-stbdb-12c ~]$ export  ORACLE_SID=stbcdb
 [oracle@oel62-stbdb-12c ~]$ rman target / 

Recovery Manager: Release 12.1.0.1.0 -  Production on Thu Aug 1 17:28:58 2014

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

connected to target database: PRMCDB  (DBID=2485119180, not open)

RMAN> alter database recover managed  standby database cancel;

using target database control file instead of  recovery catalog
   Statement processed

RMAN> shutdown immediate;

database dismounted
   Oracle instance shut down

RMAN>

  • No standby database, executar startup em estado mount eposteriormente o restore do control file via network service.
RMAN> startup nomount;

Oracle instance started

Total System Global Area     801701888 bytes
Fixed Size                   2293496 bytes
Variable Size                603980040 bytes
Database Buffers             192937984 bytes
Redo Buffers                 2490368 bytes

RMAN> restore standby controlfile from service  prmcdb ;

Starting restore at 01-AUG-13
using target database control file instead of  recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=20 device type=DISK

channel ORA_DISK_1: starting datafile backup  set restore
channel ORA_DISK_1: using network backup set  from service prmcdb
channel ORA_DISK_1: restoring control file
channel ORA_DISK_1: restore complete, elapsed  time: 00:00:07
output file  name=/u01/app/oracle/oradata/stbcdb/control01.ctl
Finished restore at 01-AUG-13

  • No standby database, alterar o estado da instance para mount e posteriormente executar o recover do database via network service.
RMAN> alter database mount;

Statement processed
 released channel: ORA_DISK_1

RMAN> recover database from service prmcdb  using compressed backupset;

Starting recover at 01-AUG-13
   Starting implicit crosscheck backup at  01-AUG-13
   allocated channel: ORA_DISK_1
   channel ORA_DISK_1: SID=30 device type=DISK
   Finished implicit crosscheck backup at  01-AUG-13

Starting implicit crosscheck copy at  01-AUG-13
   using channel ORA_DISK_1
   Crosschecked 6 objects
   Finished implicit crosscheck copy at  01-AUG-13

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

List of Cataloged Files
   =======================
   File Name:  /u01/app/oracle/fast_recovery_area/STBCDB/archivelog/2014_08_01/o1_mf_1_271_8znnpgqj_.arc
   File Name:  /u01/app/oracle/fast_recovery_area/STBCDB/archivelog/2014_08_01/o1_mf_1_269_8znnl5ob_.arc
   File Name: /u01/app/oracle/fast_recovery_area/STBCDB/archivelog/2014_08_01/o1_mf_1_270_8znnp91y_.arc
   File Name:  /u01/app/oracle/fast_recovery_area/STBCDB/archivelog/2014_08_01/o1_mf_1_277_8znnpq0s_.arc
   File Name:  /u01/app/oracle/fast_recovery_area/STBCDB/archivelog/2014_08_01/o1_mf_1_276_8znnpnyh_.arc

using channel ORA_DISK_1
   skipping datafile 5; already restored to SCN  1909218
   skipping datafile 7; already restored to SCN  1909218
   skipping datafile 8; already restored to SCN  2117817
   skipping datafile 9; already restored to SCN  2117817
   skipping datafile 10; already restored to SCN  2117817
   skipping datafile 11; already restored to SCN  2117817
   skipping datafile 12; already restored to SCN  2112866
   skipping datafile 13; already restored to SCN  2112866
   channel ORA_DISK_1: starting incremental  datafile backup set restore
   channel ORA_DISK_1: using compressed network  backup set from service prmcdb
   destination for restore of datafile 00001:  /u01/app/oracle/oradata/stbcdb/system01.dbf
   channel ORA_DISK_1: restore complete, elapsed  time: 00:00:03
   channel ORA_DISK_1: starting incremental  datafile backup set restore
   channel ORA_DISK_1: using compressed network  backup set from service prmcdb
   destination for restore of datafile 00003:  /u01/app/oracle/oradata/stbcdb/sysaux01.dbf
   channel ORA_DISK_1: restore complete, elapsed  time: 00:00:07
   channel ORA_DISK_1: starting incremental  datafile backup set restore
   channel ORA_DISK_1: using compressed network  backup set from service prmcdb
   destination for restore of datafile 00004:  /u01/app/oracle/oradata/stbcdb/undotbs01.dbf
   channel ORA_DISK_1: restore complete, elapsed  time: 00:00:07
   channel ORA_DISK_1: starting incremental  datafile backup set restore
   channel ORA_DISK_1: using compressed network  backup set from service prmcdb
   destination for restore of datafile 00006:  /u01/app/oracle/oradata/stbcdb/users01.dbf
   channel ORA_DISK_1: restore complete, elapsed  time: 00:00:01

starting media recovery

archived log for thread 1 with sequence 278  is already on disk as file /u01/app/oracle/fast_recovery_area/STBCDB/
archivelog/2014_08_01/o1_mf_1_278_8znofgvd_.arc
archived log file  name=/u01/app/oracle/fast_recovery_area/STBCDB/archivelog/2014_08_01/
o1_mf_1_278_8znofgvd_.arc  thread=1 sequence=278
media recovery complete, elapsed time:  00:00:01

Finished recover at 01-AUG-13

 

  • Iniciando Redo apply process (processo de aplicação de redo).
RMAN> alter database recover managed  standby database disconnect from session;

Statement processed

RMAN> select * from v$archive_gap;

no rows selected

Archive Gap resolvido usando a new feature do RMAN "Restore/Recover files over network" na versão 12c.

Conclusão:

Oracle Data Guard é hábil para resolver redo gaps automaticamente, exceto quando há problemas como corrupção ou remoção de archivelogs nos database primário ou standby. Por isso é importante a realização frequente de backup dos archivelogs, pois em caso de eventual problema (corrupção ou remoção) é possível um restore dos archivelog para seu diretório de origem, com isso o Data Guard resolvera o redo gap. Caso não houver um backup dos archivelogs, duas outras opções são possíveis  backup incremental com RMAN para execução de Roll-Forward ou restore/recover de arquivos de banco de dados remotamente com RMAN para execução de Roll-Forward.



Joel é um DBA Especialista (Oracle ACE Director, OCM Cloud Admin. & OCM11g ). Com mais de 14 anos de experiência do mundo Oracle Technology, especializado em arquitetura e implementação de soluções como: Cloud, Alta disponibilidade, Disaster/Recovery, Upgrades, replicação e todos as áreas relacionadas com bancos de dados Oracle. Consultor internacional com deveres, conferências e atividades em mais de 50 países e inúmeros clientes em todo o mundo. Palestrante regular nos eventos Oracle em todo o mundo como: OTN LAD, OTN MENA, OTN APAC e muito mais. Joel sempre foi conhecido por ser pioneiro em tecnologia Oracle desde os primeiros dias de sua carreira sendo o primeiro latino-americano premiado como "OTN Expert" no ano de 2003 pela Oracle Corporation, um dos primeiros "ACE Oracle" no Oracle ACE Program no ano de 2004, um dos primeiros OCP Database Cloud Administrator em todo o mundo no ano de 2013 e como um das maiores realizações profissionais em sua carreira, recentemente ele foi homenageado como o primeiro "OCM Database Cloud Administrator" do mundo.

Mahir é um DBA Sênior com 10 anos de experiência em Oracle Database com foco em High Availability e Disaster Recovery Solutions (RAC, Data Guard, RMAN...). Mahir trabalha atualmente no Banco Central da Republica do Azerbaijão. Ele é um OCE DBA. Mahir é membro do Azerbaijan Oracle User Group (AZEROUG).

Furushima é um DBA Sênior com vasta experiência e conhecimento em diversas áreas de banco de dados relacional é especialista em “Performance, diagnostic e tuning”, High Availability e Backup & Recovery, nos últimos anos de sua carreira profissional Furushima acumulou cargos de DBA Oracle e SysAdmin em sistemas operacional Unix, atualmente trabalha para Grupo Camargo Correa SA.

Este artigo foi revisto pela equipe de produtos Oracle e está em conformidade com as normas e práticas para o uso de produtos Oracle.