Olá, pessoal! Segue abaixo um procedimento sobre como realizar recover de database que não possui todos os archivelogs restaurados. Este é um processo bem conhecido, porém resolvi postar um “step-by-step”. Como são parte do processo de recover, os archivelogs são necessários. Este processo mostrará como realizar um recover de um database que não possui todos os archives solicitados pelo recover.

Imagine que sua equipe de backup (ou você mesmo sendo o responsável) não encontre todos os archiveslogs de um backup qualquer, então, como realizar o recover do seu database?

Erro:

SQL> recover database until cancel using backup controlfile;
ORA-00279: change 9867098396261 generated at 09/10/2011 14:22:14 needed for
thread 1
ORA-00289: suggestion : /archives/ORADB/arclog_098396261_2191.arc
ORA-00280: change 9867098396261 for thread 1 is in sequence #2191

Specify log: {=suggested | filename | AUTO | CANCEL}
cancel
ORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS would get error below
ORA-01195: online backup of file 1 needs more recovery to be consistent
ORA-01110: data file 1: ‚/archives/ORADB/SYSTEM01_ORADB.dbf‚
ORA-01112: media recovery not started

SQL> alter database open resetlogs;
alter database open resetlogs
*
ERROR at line 1:
ORA-01195: online backup of file 1 needs more recovery to be consistent
ORA-01110: data file 1: ‚/archives/ORADB/SYSTEM01_DB.dbf

Neste cenário, podemos utilizar o parâmetro: (_ALLOW_RESETLOGS_CORRUPTION=TRUE), que permite que o Database seja aberto mesmo faltando recover em alguns datafiles.

O que poderemos identificar é que várias mensagens de erro (geralmente ORA-0600) surgirão no <Alert.log>, visto que o Database será aberto de forma “forçada”.

Erros:

Errors in file /u01/ORADB/admin/ORADB/udump/ORADB_ora_9225.trc:
ORA-00600: internal error code, arguments: [4194], [17], [9], [], [], [], [], []
Tue Mar 25 12:45:55 2008
Errors in file /u01/ORADB/admin/ORADB/bdump/ORADB_smon_24975.trc:
ORA-00600: internal error code, arguments: [4193], [53085], [50433], [], [], [], [], []
Doing block recovery for file 433 block 13525
Block recovery from logseq 2, block 31 to scn 9867098396261

Para resolver os erros de blocos corrompidos na UNDO, basta mudar o parâmetro UNDO_MANAGEMENT para MANUAL, no init.ora. Neste momento, será possível abrir o banco de dados normalmente. Uma vez aberto o banco de dados, o ideal é criar uma nova tablespace de UNDO, realizar um novo backup full (usando RMAN preferencialmente ou EXPDP) e, depois, recriar o banco novamente.

De acordo com o Metalink, não é garantido que utilizar o parâmetro _ALLOW_RESETLOGS_CORRUPTION=TRUE irá abrir o banco de dados com sucesso; esta é apenas uma maneira de “contornar” (workaround) o problema. De qualquer maneira, a recomendação, assim que abrir o database, é realizar um backup full, recriar o database e depois importar o backup realizado.

Plano:

1. Usar _ALLOW_RESETLOGS_CORRUPTION=TRUE no arquivo init.ora;
2. Startup Mount;
3. Recover database;
4. Alter database open resetlogs;
5. Setar undo_management para MANUALin no arquivo init.ora;
6. Startup ;
7. Criar uma nova UNDO tablespace;
8. Mudar o undo_management para AUTO e o undo_tablespace para uma Nova tablesapce;
9. Realizar um Backup completo via EXPDP;
10. Criar um novo banco de dados, limpo, via CREATE DATABASE;
11. Importar o backup gerado no passo 9, usando IMPDP;
12. Realizar testes de funcionalidades e integridade;
13. Dropar o Database antigo.

p.s.: como citado anteriormente, esta é uma maneira de “forçar” a abertura do banco de dados e deve ser usada somente se não houver mais alternativas de realizar um recover corretamente.

Abraço!