Aplicando Arquivos de Redo Log Arquivados em um Cold Backup
Não é raro vermos em fóruns ou grupos de discussões, questões ou dúvidas relacionadas à aplicação de arquivos de redo log arquivados (archive redo log files) em backups frios (cold backups) de banco de dados Oracle. Apenas para relembrar, um “cold backup” gerenciado por usuário é uma opção de backup na qual o mesmo é realizado no nível de arquivo, onde todos os arquivos de dados, arquivos de controle e opcionalmente os arquivos de redo log on-line são copiados através de comandos do sistema operacional. Nas plataformas Unix/Linux, comandos tais como cp ou tar, normalmente são usados para fazer o backup dos arquivos para um local seguro.
Esta operação de cópia dos arquivos de banco de dados é realizada enquanto o banco de dados está fechado. Por outro lado, para quem utiliza a estratégia de backup gerenciada pelo servidor RMAN, um cold backup para ser realizado necessita que o banco de dados esteja no estado montado (MOUNT), mas não aberto.
“No caso de backups gerenciados pelo usuário, um dos erros mais comuns quando se usa o cold backup é não fechar o banco de dados normalmente com as opções NORMAL, IMMEDIATE ou TRANSACTIONAL do comando SHUTDOWN. Os colds backups executados com o banco de dados aberto ou após ele ter sido fechado de modo anormal são completamente inúteis. Essa situação potencialmente perigosa pode ocorrer quando são usados scripts automatizados que não contêm uma lógica para verificar se o banco de dados foi realmente fechado normalmente antes do início do backup.”
Dependendo da política de backup implementada e do tipo de desastre ocorrido no servidor do banco de dados, talvez sempre existirá a possibilidade de contar com pelo menos um “cold backup” do banco de dados e um backup de todos os arquivos de redo log gerados após a realização do cold backup.
No mais, neste artigo irei simular a aplicação de todos os arquivos de redo log arquivados criados após a realização de um cold backup, nos arquivos de banco de dados restaurados do próprio cold backup. Não precisa nem dizer que o banco de dados deverá estar configurado para operar no modo de arquivamento (ARCHIVELOG) …
[oracle@linux1 oracle]$ sqlplus / as sysdba
SQL*Plus: Release 10.2.0.4.0 - Production on Qua Abr 15 13:28:52 2009
Copyright (c) 1982, 2007, Oracle. All Rights Reserved.
Conectado a uma instância inativa.
SQL> startup
Instância ORACLE iniciada.
Total System Global Area 155189248 bytes
Fixed Size 1266320 bytes
Variable Size 100666736 bytes
Database Buffers 50331648 bytes
Redo Buffers 2924544 bytes
Banco de dados montado.
Banco de dados aberto.
-- Confirmando o formato dos archive logs
SQL> show parameter log_archive_format
NAME TYPE VALUE
------------------------ ----------- ------------------------------
log_archive_format string %t_%s_%r.dbf
-- Confirmando o destino para os archive redo logs gerados
SQL> show parameter log_archive_dest_1
NAME TYPE VALUE
--------------------- ----------- ---------------------------------------
log_archive_dest_1 string LOCATION=/u01/archive/ MANDATORY REOPEN
-- Confirmando que o banco de dados está no modo de arquivamento
SQL> archive log list
Modo log de banco de dados Modo de Arquivamento
Arquivamento automático Ativado
Destino de arquivamento /u01/archive/
A seqüência de log on-line mais antiga 1
Próxima seqüência de log a arquivar 1
Seqüência de log atual 1
-- Confirmando a seqüencia do arquivo de redo log-online corrente
SQL> select group#,thread#,sequence#,bytes,members,archived,status from v$log;
GROUP# THREAD# SEQUENCE# BYTES MEMBERS ARC STATUS
---------- ---------- ---------- ---------- ---------- --- ----------------
1 1 1 4194304 1 NO CURRENT
2 1 0 4194304 1 YES UNUSED
3 1 0 4194304 1 YES UNUSED
-- Fechando o banco de dados
SQL> shutdown immediate
Banco de dados fechado.
Banco de dados desmontado.
Instância ORACLE desativada.
SQL> exit
Desconectado de Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - Production
With the Partitioning, OLAP, Data Mining and Real Application Testing optionsIrei abaixo realizar uma cópia de todos os arquivos de banco de dados para um outro local.
[oracle@linux1 oracle]$ cp -a /u01/app/oracle/oradata /backupApós a realização do cold backup, irei reiniciar o banco de dados para simular algumas transações.
oracle@linux1 oracle]$ sqlplus / as sysdba
SQL*Plus: Release 10.2.0.4.0 - Production on Qua Abr 15 13:28:52 2009
Copyright (c) 1982, 2007, Oracle. All Rights Reserved.
Conectado a uma instância inativa.
SQL> startup
Instância ORACLE iniciada.
Total System Global Area 155189248 bytes
Fixed Size 1266320 bytes
Variable Size 100666736 bytes
Database Buffers 50331648 bytes
Redo Buffers 2924544 bytes
Banco de dados montado.
Banco de dados aberto.
-- Criando um usuário de teste
SQL> create user scott identified by tiger default tablespace users;
Usuário criado.
-- Concedendo atribuições padrão
SQL> grant connect,resource to scott;
Concessão bem-sucedida.
-- Conectando com o usuário SCOTT
SQL> connect scott/tiger
Conectado.
-- Criando uma tabela de teste
SCOTT> create table t1 (id number);
Tabela criada.Realizado a etapa acima, abaixo irei simular algumas operações DML no banco de dados de forma a gerar registros de redo suficientes para a criação de arquivos de redo log arquivados:
SCOTT> insert into t1 select level from dual connect by level <= 100000;
100000 linhas criadas.
SCOTT> commit;
Commit concluído.
SCOTT> update t1 set id=1000;
100000 linhas atualizadas.
SCOTT> rollback;
Rollback concluído.
SCOTT> drop table t1 purge;
Tabela eliminada.
SCOTT> create table t2 (data timestamp);
Tabela criada.
-- Inserindo a data e horário atual
SCOTT> insert into t2 select localtimestamp from dual;
1 linha criada.
SCOTT> commit;
Commit concluído.
SCOTT> select * from t2;
DATA
--------------------------
15/04/2009 13:34:36,883986
SQL> connect / as sysdba;
Conectado.
-- Forçando o arquivamento do arquivo de redo log on-line corrente
SQL> alter system archive log current;
Sistema alterado.Após a simulação das operações acima, podemos ver abaixo que foram gerados 12 arquivos de redo log arquivados.
SQL> select recid,name from v$archived_log;
RECID NAME
---------- -----------------------------------------
1 /u01/archive/1_1_684148997.dbf
2 /u01/archive/1_2_684148997.dbf
3 /u01/archive/1_3_684148997.dbf
4 /u01/archive/1_4_684148997.dbf
5 /u01/archive/1_5_684148997.dbf
6 /u01/archive/1_6_684148997.dbf
7 /u01/archive/1_7_684148997.dbf
8 /u01/archive/1_8_684148997.dbf
9 /u01/archive/1_9_684148997.dbf
10 /u01/archive/1_10_684148997.dbf
11 /u01/archive/1_11_684148997.dbf
12 /u01/archive/1_12_684148997.dbf
12 linhas selecionadas.
-- Fechando o banco de dados
SQL> shutdown immediate
Banco de dados fechado.
Banco de dados desmontado.
Instância ORACLE desativada.
SQL> exit
Desconectado de Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
-- Confirmando os registros de redo log criados no destino de arquivamento
[oracle@linux1 archive]$ ls -lhatr
total 46M
drwxrwxr-x 4 oracle dba 4,0K Abr 15 13:31 ..
-rw-r----- 1 oracle oinstall 4,0M Abr 15 13:34 1_1_684148997.dbf
-rw-r----- 1 oracle oinstall 4,0M Abr 15 13:34 1_2_684148997.dbf
-rw-r----- 1 oracle oinstall 4,0M Abr 15 13:34 1_3_684148997.dbf
-rw-r----- 1 oracle oinstall 4,0M Abr 15 13:34 1_4_684148997.dbf
-rw-r----- 1 oracle oinstall 4,0M Abr 15 13:34 1_5_684148997.dbf
-rw-r----- 1 oracle oinstall 4,0M Abr 15 13:34 1_6_684148997.dbf
-rw-r----- 1 oracle oinstall 4,0M Abr 15 13:34 1_7_684148997.dbf
-rw-r----- 1 oracle oinstall 4,0M Abr 15 13:34 1_8_684148997.dbf
-rw-r----- 1 oracle oinstall 4,0M Abr 15 13:34 1_9_684148997.dbf
-rw-r----- 1 oracle oinstall 4,0M Abr 15 13:34 1_10_684148997.dbf
-rw-r----- 1 oracle oinstall 4,0M Abr 15 13:34 1_11_684148997.dbf
-rw-r----- 1 oracle oinstall 1,5M Abr 15 13:35 1_12_684148997.dbf
drwxr-xr-x 2 oracle oinstall 20K Abr 15 13:35 .
-- Simulando a perda de todos os arquivos de banco de dados
[oracle@linux1 oracle]$ rm -rf /u01/app/oracle/oradata
-- Restaurando o cold backup para o local de origem
[oracle@linux1 oracle]$ cp -a /backup/oradata /u01/app/oracle/oradata
[oracle@linux1 oracle]$ sqlplus / as sysdba
SQL*Plus: Release 10.2.0.4.0 - Production on Qua Abr 15 13:47:19 2009
Copyright (c) 1982, 2007, Oracle. All Rights Reserved.
Conectado a uma instância inativa.
SQL> startup mount
Instância ORACLE iniciada.
Total System Global Area 155189248 bytes
Fixed Size 1266320 bytes
Variable Size 100666736 bytes
Database Buffers 50331648 bytes
Redo Buffers 2924544 bytes
Banco de dados montado.
SQL> recover database;
ORA-00283: sessão de recuperação cancelada devido a erros
ORA-00264: nenhuma recuperação necessáriaApenas para validar o cold backup, podemos perceber acima como era de se esperar, que o comando RECOVER DATABASE falhou, pelo fato de os arquivos de banco de dados já estarem consistentes e, portanto, não haveria nenhuma necessidade de qualquer tipo de recuperação.
Como poderemos então aplicar os arquivos de redo log arquivados sobre este banco de dados de modo a reconstruir todas as transações realizadas anteriormente? A chave para isso é utilizar o comando RECOVER DATABASE em conjunto com a cláusula USING BACKUP CONTROLFILE sendo que, a cláusula UNTIL CANCEL poderá ser utilizada agora ou depois, como demonstrarei mais a frente. Neste caso, podemos dizer que os arquivos de controle restaurados, na verdade, são realmente backups dos arquivos de controle. Selecionarei a opção AUTO para que eu não precise confirmar os arquivos de redo log arquivados um a um.
SQL> recover database using backup controlfile;
ORA-00279: alterar 187046 gerado em 04/15/2009 13:31:13 necessário para o thread 1
ORA-00289: sugestão : /u01/archive/1_1_684148997.dbf
ORA-00280: alterar 187046 para o thread 1 está na seqüência #1
Especificar log: {=nome de arquivo | sugerido | AUTO | CANCEL}
AUTO
ORA-00279: alterar 187315 gerado em 04/15/2009 13:34:12 necessário para o thread 1
ORA-00289: sugestão : /u01/archive/1_2_684148997.dbf
ORA-00280: alterar 187315 para o thread 1 está na seqüência #2
ORA-00278: o arquivo de log '/u01/archive/1_1_684148997.dbf' não é mais
necessário para esta recuperação
ORA-00279: alterar 187390 gerado em 04/15/2009 13:34:13 necessário para o thread 1
ORA-00289: sugestão : /u01/archive/1_3_684148997.dbf
ORA-00280: alterar 187390 para o thread 1 está na seqüência #3
ORA-00278: o arquivo de log '/u01/archive/1_2_684148997.dbf' não é mais
necessário para esta recuperação
ORA-00279: alterar 187467 gerado em 04/15/2009 13:34:15 necessário para o thread 1
ORA-00289: sugestão : /u01/archive/1_4_684148997.dbf
ORA-00280: alterar 187467 para o thread 1 está na seqüência #4
ORA-00278: o arquivo de log '/u01/archive/1_3_684148997.dbf' não é mais
necessário para esta recuperação
ORA-00279: alterar 187541 gerado em 04/15/2009 13:34:16 necessário para o thread 1
ORA-00289: sugestão : /u01/archive/1_5_684148997.dbf
ORA-00280: alterar 187541 para o thread 1 está na seqüência #5
ORA-00278: o arquivo de log '/u01/archive/1_4_684148997.dbf' não é mais
necessário para esta recuperação
ORA-00279: alterar 187617 gerado em 04/15/2009 13:34:20 necessário para o thread 1
ORA-00289: sugestão : /u01/archive/1_6_684148997.dbf
ORA-00280: alterar 187617 para o thread 1 está na seqüência #6
ORA-00278: o arquivo de log '/u01/archive/1_5_684148997.dbf' não é mais
necessário para esta recuperação
ORA-00279: alterar 187693 gerado em 04/15/2009 13:34:21 necessário para o thread 1
ORA-00289: sugestão : /u01/archive/1_7_684148997.dbf
ORA-00280: alterar 187693 para o thread 1 está na seqüência #7
ORA-00278: o arquivo de log '/u01/archive/1_6_684148997.dbf' não é mais
necessário para esta recuperação
ORA-00279: alterar 187769 gerado em 04/15/2009 13:34:22 necessário para o thread 1
ORA-00289: sugestão : /u01/archive/1_8_684148997.dbf
ORA-00280: alterar 187769 para o thread 1 está na seqüência #8
ORA-00278: o arquivo de log '/u01/archive/1_7_684148997.dbf' não é mais
necessário para esta recuperação
ORA-00279: alterar 187909 gerado em 04/15/2009 13:34:26 necessário para o thread 1
ORA-00289: sugestão : /u01/archive/1_9_684148997.dbf
ORA-00280: alterar 187909 para o thread 1 está na seqüência #9
ORA-00278: o arquivo de log '/u01/archive/1_8_684148997.dbf' não é mais
necessário para esta recuperação
ORA-00279: alterar 187982 gerado em 04/15/2009 13:34:27 necessário para o thread 1
ORA-00289: sugestão : /u01/archive/1_10_684148997.dbf
ORA-00280: alterar 187982 para o thread 1 está na seqüência #10
ORA-00278: o arquivo de log '/u01/archive/1_9_684148997.dbf' não é mais
necessário para esta recuperação
ORA-00279: alterar 188055 gerado em 04/15/2009 13:34:28 necessário para o thread 1
ORA-00289: sugestão : /u01/archive/1_11_684148997.dbf
ORA-00280: alterar 188055 para o thread 1 está na seqüência #11
ORA-00278: o arquivo de log '/u01/archive/1_10_684148997.dbf' não é mais
necessário para esta recuperação
ORA-00279: alterar 188127 gerado em 04/15/2009 13:34:32 necessário para o thread 1
ORA-00289: sugestão : /u01/archive/1_12_684148997.dbf
ORA-00280: alterar 188127 para o thread 1 está na seqüência #12
ORA-00278: o arquivo de log '/u01/archive/1_11_684148997.dbf' não é mais
necessário para esta recuperação
ORA-00279: alterar 188197 gerado em 04/15/2009 13:35:05 necessário para o thread 1
ORA-00289: sugestão : /u01/archive/1_13_684148997.dbf
ORA-00280: alterar 188197 para o thread 1 está na seqüência #13
ORA-00278: o arquivo de log '/u01/archive/1_12_684148997.dbf' não é mais
necessário para esta recuperação
ORA-00308: não é possível abrir o log '/u01/archive/1_13_684148997.dbf arquivado'
ORA-27037: não é possível obter status do arquivo
Linux Error: 2: No such file or directory
Additional information: 3Agora a pergunta que não quer calar: Como é possível o arquivo de controle saber da existência dos arquivos de redo log arquivados sendo que os mesmos não foram gerados anteriormente (antes do cold backup)? Na verdade, ele não sabe e nem teria como saber, então podemos chegar a conclusão de que este é um comportamento padrão quando utilizamos a cláusula USING BACKUP CONTROLFILE do comando RECOVER DATABASE, ou seja, o processo de recuperação irá perguntar automaticamente e de forma seqüencial por arquivos de redo log arquivados e, caso o processo localize o arquivo de redo log arquivado, o mesmo será fornecido como opção para ser aplicado até o momento em que desejarmos cancelar a operação (CANCEL).
SQL> alter database open resetlogs;
alter database open resetlogs
*
ERRO na linha 1:
ORA-01113: o arquivo 1 precisa da recuperação de mídia
ORA-01110: 1 do arquivo de dados: '/u01/app/oracle/oradata/BD01/system01.dbf'Podemos ver acima que após a aplicação de todos os arquivos de redo log arquivados possíveis (logs de 1 até 12), mesmo assim ainda não foi possível abrir o banco de dados, isso porque será necessário sinalizar o final do processo de recuperação utilizando a cláusula UNTIL CANCEL, pois o arquivo de redo log arquivado 1_13_684148997.dbf apesar de não existir, realmente não seria necessário como demonstrado abaixo:
SQL> recover database using backup controlfile until cancel;
ORA-00279: alterar 188197 gerado em 04/15/2009 13:35:05 necessário para o thread 1
ORA-00289: sugestão : /u01/archive/1_13_684148997.dbf
ORA-00280: alterar 188197 para o thread 1 está na seqüência #13
Especificar log: {=nome de arquivo | sugerido | AUTO | CANCEL}
CANCEL
recuperação de mídia cancelada.Pronto. Após aplicados todos os arquivos de redo log arquivados possíveis, poderemos então abrir o banco de dados com a opção RESETLOGS.
SQL> alter database open resetlogs;
Banco de dados alterado.Apenas para certificar que o banco de dados foi realmente recuperado até a última transação, selecionarei o registro da tabela SCOTT.T2 criada antes da realização do cold backup, para verificar se o registro inserido foi recuperado com sucesso.
SQL> connect scott/tiger
Conectado.
SQL> select * from t2;
DATA
--------------------------
15/04/2009 13:34:36,883986