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;
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:
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.