Olá,
Recentemente, um conhecido de um amigo meu me contactou desesperado dizendo que o seu banco de dados Oracle Database 10g Express Edition não funcionava mais, e que ele precisava urgentemente recuperar os dados de um schema de banco de dados, pois o último backup lógico que ele tinha era de 3 semanas atrás e que seria praticamente inviável entrar com todas as informações manualmente por causa do grande volume de dados a serem processados. Depois de ter pesquisado (em fóruns de discussão, etc...) ele resolveu recriar os arquivos de controle (control files), mas mesmo assim o banco de dados não subiu. Bem, após este relato eu formulei 6 perguntas simples:
* Qual é realmente o problema?
* O que o arquivo de log de alerta informou?
* Por que foi necessário recriar os arquivos de controle?
* Foi realizado um backup físico antes de tentar qualquer tipo de recuperação?
* O banco de dados está no modo de arquivamento (ARCHIVELOG)?
* Você realmente sabe o que está fazendo?
Como ele respondeu que não tinha realizado nenhum backup físico e não sabia exatamente o que estava fazendo, então eu disse que se antes a situação já não estava boa, agora que poderia estar pior ainda, e que infelizmente talvez fosse impossível recuperar os dados. Bem, se os dados são críticos, então o ideal é consultar um especialista e não ficar brincando de DBA ... Antes de mais nada, é altamente recomendável realizar um backup físico dos arquivos de banco de dados (datafiles, control files, redo log files, etc...) antes de realizar qualquer ação que envolva recovery (recuperação).
Neste artigo irei demonstrar o que foi feito para que o banco de dados fosse aberto após ele me enviar apenas os arquivos de banco de dados, pois o arquivo de log de alerta por algum motivo tinha sido apagado...
Após eu baixar os arquivos de banco de dados para minha máquina ...
C:\>sqlplus / as sysdba
SQL*Plus: Release 10.1.0.2.0 - Production on Qua Dez 3 10:24:25 2008
Copyright (c) 1982, 2004, Oracle. All rights reserved.
Conectado a uma instância inativa.
SYS> startup
Instância ORACLE iniciada.
Total System Global Area 285212672 bytes
Fixed Size 1287016 bytes
Variable Size 121638040 bytes
Database Buffers 159383552 bytes
Redo Buffers 2904064 bytes
Banco de dados montado.
ORA-01589: use a opção RESETLOGS ou NORESETLOGS para o banco de dados aberto
SYS> 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: 'C:\ORACLEXE\ORADATA\XE\SYSTEM.DBF'
Podemos ver acima que o erro ORA-01113 foi emitido informado que o arquivo de dados SYSTTEM.DBF pertencente ao tablespace SYSTEM precisa de recuperação de mídia. Irei confirmar abaixo, que o banco de dados não foi aberto ficando portando no estado MOUNT (montado).
SYS> select status from v$instance;
STATUS
------------
MOUNTED
SYS> select * from v$log;
GROUP# THREAD# SEQUENCE# BYTES MEMBERS ARC STATUS
---------- ---------- ---------- ---------- ---------- --- -----------
1 1 0 52428800 1 YES UNUSED
2 1 0 52428800 1 YES CURRENT
Podemos ver pelo resultado da view V$LOG acima e pelo comando archive log list abaixo, que realmente as seqüências de log foram resetadas pelo fato de o arquivo de controle ter sido recriado. Podemos ver também que o banco de dados não está operando no modo de arquivamento (ARCHIVELOG)
SYS> archive log list
Modo log de banco de dados Modo Sem Arquivamento
Arquivamento automático Desativado
Destino de arquivamento USE_DB_RECOVERY_FILE_DEST
A seqüência de log on-line mais antiga 0
Seqüência de log atual 0
SYS> select controlfile_created,open_mode,open_resetlogs,log_mode from v$database;
CONTROLFIL OPEN_MODE OPEN_RESETL LOG_MODE
---------- ---------- ----------- ------------
28/11/2008 MOUNTED REQUIRED NOARCHIVELOG
O resultado acima nos mostra que o arquivo de controle foi recriado no dia 28/11/2008, que o banco de dados se encontra no estado MOUNT, que para abertura do banco de dados é necessário utilizar a opção RESETLOGS, e que o mesmo não foi configurado para operar em modo de arquivamento (ARCHIVELOG).
SYS> select * from v$recover_file;
FILE# ONLINE ONLINE_ ERROR CHANGE# TIME
---------- ------- ------- ------------------------------- ---------- ----------
1 ONLINE ONLINE 19312058 17/11/2008
2 ONLINE ONLINE 19312058 17/11/2008
3 ONLINE ONLINE 19312058 17/11/2008
4 ONLINE ONLINE 19312058 17/11/2008
O resultado acima nos mostra que os arquivos de dados se encontram em um estado inconsistente e que os mesmos necessitam de recuperação para que fiquem sincronizados com o arquivo de controle. A coluna CHANGE# nos mostra o SCN a partir do qual a recuperação deve ser iniciada.
SYS> select * from v$recovery_log;
não há linhas selecionadas
O resultado acima indica que apenas os arquivos de redo log on-line seriam necessários para recuperar o banco de dados. Na verdade, não posso dizer isso com certeza, pelo fato de o arquivo de controle ter sido recriado. O resultado abaixo selecionado da view V$DATAFILE nos mostra que todos os arquivos de dados necessitam de recuperação.
SYS> select file#,checkpoint_change#,status from v$datafile;
FILE# CHECKPOINT_CHANGE# STATUS
---------- ------------------ -------
1 19312058 SYSTEM
2 19312058 RECOVER
3 19312058 RECOVER
4 19312058 RECOVER
Como o arquivo de controle foi recriado, irei utilizar o comando RECOVER DATABASE juntamente com a cláusula USING BACKUP CONTROLFILE para ver o que será mostrado:
SYS> recover database using backup controlfile;
ORA-00279: alterar 19312058 gerado em 17/11/2008 15:45:31 necessário para o thread 1
ORA-00289: sugestão : C:\ORACLEXE\APP\ORACLE\FLASH_RECOVERY_AREA\XE\O1_MF_1_19327_%U_.ARC
ORA-00280: alterar 19312058 para o thread 1 está na seqüência #19327
Especificar log: {=nome de arquivo | sugerido | AUTO | CANCEL}
cancel
Recuperação de mídia cancelada.
Podemos ver acima que para a recuperação completa do banco de dados, seria necessário utilizar os dados de redo contidos no arquivo de redo log on-line que estivesse segurando a seqüência 19327. Percebi também que tanto o arquivo de controle quanto os arquivo de redo log on-line não estão multiplexados. Portanto, vale a pena salientar que mesmo que esteja sendo utilizado uma versão do Oracle 10g Express Edition, multiplexar estes arquivos é de fundamental importância para a segurança do banco de dados.
A questão agora é: É possível abrir este banco de dados? Bem, após mostrar a situação em que este banco de dados se encontra, irei demonstrar abaixo um último recurso que pode salvar o dia. Existe um parâmetro de inicialização não documentado chamado "_allow_resetlogs_corruption" que pode ser utilizado em caso de emergência e como último recurso após todas as tentativas possíveis para recuperar um banco de dados tiverem falhado. É bom ficar claro que a Oracle não prestará suporte a nenhum banco de dados que se utilizou deste recurso, a não ser que os dados sejam exportados (FULL EXPORT) para um outro banco de dados. Vale a pena salientar também que não há 100% de garantia de que um banco de dados sempre será aberto através desse recurso, e que isso com certeza irá depender de cada caso.
Na teoria, tendo este parâmetro setado como TRUE, será possível abrir o banco de dados mesmo que os SCNs não estejam sincronizados, ou seja, o Oracle não irá checar a consistência entre os arquivos de dados, arquivos de controle e arquivos de redo log on-line. Após a abertura do banco de dados o mesmo estará em um estado inconsistente. Portanto, é recomendável realizar uma exportação completa o mais rápido possível após a abertura do banco de dados.
Abaixo irei demonstrar como setar este parâmetro ...
-- Irei criar um arquivo de inicialização pfile
SYS> create pfile='C:\pfile.ora' from spfile;
Arquivo criado.
-- Irei baixar o banco de dados
SYS> shutdown immediate
ORA-01109: banco de dados não aberto
Banco de dados desmontado.
Instância ORACLE desativada.
SYS> exit
Desconectado
-- Irei editar o arquivo de inicialização criado anteriormente, de forma a incluir o
-- parâmetro _allow_resetlogs_corruption e setá-lo com TRUE
C:\>type pfile.ora
xe.__db_cache_size=159383552
xe.__java_pool_size=4194304
xe.__large_pool_size=16777216
xe.__shared_pool_size=92274688
xe.__streams_pool_size=8388608
*.audit_file_dest='C:\oraclexe\app\oracle\admin\XE\adump'
*.background_dump_dest='C:\oraclexe\app\oracle\admin\XE\bdump'
*.compatible='10.2.0.1.0'
*.control_files='C:\oraclexe\oradata\XE\control.dbf'
*.core_dump_dest='C:\oraclexe\app\oracle\admin\XE\cdump'
*.db_name='XE'
*.DB_RECOVERY_FILE_DEST_SIZE=10G
*.DB_RECOVERY_FILE_DEST='C:\oraclexe\app\oracle\flash_recovery_area'
*.dispatchers='(PROTOCOL=TCP) (SERVICE=XEXDB)'
*.job_queue_processes=4
*.open_cursors=300
*.os_authent_prefix=''
*.pga_aggregate_target=90M
*.remote_login_passwordfile='EXCLUSIVE'
*.resumable_timeout=0
*.sessions=20
*.sga_target=270M
*.shared_servers=4
*.undo_management='AUTO'
*.undo_tablespace='UNDO'
*.user_dump_dest='C:\oraclexe\app\oracle\admin\XE\udump'
*._allow_resetlogs_corruption=TRUE
C:\>sqlplus / as sysdba
SQL*Plus: Release 10.1.0.2.0 - Production on Qua Dez 3 10:59:02 2008
Copyright (c) 1982, 2004, Oracle. All rights reserved.
Conectado a uma instância inativa.
-- Irei inicializar a instância com o pfile criado anteriormente
SYS> startup pfile=pfile.ora
Instância ORACLE iniciada.
Total System Global Area 285212672 bytes
Fixed Size 1287016 bytes
Variable Size 121638040 bytes
Database Buffers 159383552 bytes
Redo Buffers 2904064 bytes
Banco de dados montado.
ORA-01589: use a opção RESETLOGS ou NORESETLOGS para o banco de dados aberto
-- Irei abrir o banco de dados com a opção RESETLOGS
SYS> alter database open resetlogs;
Banco de dados alterado.
Pronto. A partir de agora é só realizar a exportação dos dados desejados ou até mesmo realizar uma exportação completa do banco de dados.
-- Verificando o estado da instância
SYS> select status from v$instance;
STATUS
------------
OPEN
No caso do meu "amigo", o que realmente interessa é salvar os dados do schema ORACLE_DATA
SYS> select * from all_users;
USERNAME USER_ID CREATED
------------------------------ ---------- ----------
ORACLE_DATA 36 18/12/2007
FLOWS_020100 35 07/02/2006
FLOWS_FILES 34 07/02/2006
HR 33 07/02/2006
MDSYS 32 07/02/2006
ANONYMOUS 28 07/02/2006
XDB 27 07/02/2006
CTXSYS 25 07/02/2006
DBSNMP 23 07/02/2006
TSMSYS 20 07/02/2006
DIP 18 07/02/2006
OUTLN 11 07/02/2006
SYSTEM 5 07/02/2006
SYS 0 07/02/2006
14 linhas selecionadas.
SYS> exit
Desconectado de Oracle Database 10g Express Edition Release 10.2.0.1.0 - Production
Irei agora exportar o usuário ORACLE_DATA utilizando o utilitário de exportação exp.
C:\>exp system/***** file=backup owner=oracle_data statistics=none
Export: Release 10.1.0.2.0 - Production on Qua Dez 3 11:03:27 2008
Copyright (c) 1982, 2004, Oracle. All rights reserved.
Conectado a: Oracle Database 10g Express Edition Release 10.2.0.1.0 - Production
Exportação executada no conjunto de caracteres de WE8PC850 e no conjunto de
caracteres de AL16UTF16 NCHAR o servidor usa WE8MSWIN1252 conjunto de caracteres
(conversão de conjunto de caracteres possível)
Sobre exportar usuários especificados ...
. exportando objetos e ações procedurais anteriores ao esquema
. exportando os nomes da biblioteca de função externa para usuário ORACLE_DATA
. exportando sinônimos do tipo PÚBLICO
. exportando sinônimos do tipo privado
. exportando definições de tipos de objeto para usuário ORACLE_DATA
Sobre exportar objetos de ORACLE_DATA ...
. exportando vínculos de banco de dados
. exportando números de seqüência
. exportando definições de cluster
EXP-00056: Erro Oracle: 25153 encontrado
ORA-25153: O Tablespace Temporário está Vazio
EXP-00000: Exportação encerrada sem êxito
C:\>sqlplus / as sysdba
SQL*Plus: Release 10.1.0.2.0 - Production on Qua Dez 3 11:04:07 2008
Copyright (c) 1982, 2004, Oracle. All rights reserved.
Conectado a:
Oracle Database 10g Express Edition Release 10.2.0.1.0 - Production
SYS> select * from v$tempfile;
não há linhas selecionadas
SYS> alter tablespace temp add tempfile 'C:\oraclexe\oradata\XE\temp.dbf' reuse;
Tablespace alterado.
SYS> exit
Desconectado de Oracle Database 10g Express Edition Release 10.2.0.1.0 - Production
-- Irei novamente tentar exportar o usuário ORACLE_DATA
C:\>exp system/***** file=backup owner=oracle_data statistics=none
Export: Release 10.1.0.2.0 - Production on Qua Dez 3 11:07:00 2008
Copyright (c) 1982, 2004, Oracle. All rights reserved.
Conectado a: Oracle Database 10g Express Edition Release 10.2.0.1.0 - Production
Exportação executada no conjunto de caracteres de WE8PC850 e no conjunto de
caracteres de AL16UTF16 NCH o servidor usa WE8MSWIN1252 conjunto de caracteres
(conversão de conjunto de caracteres possível)
Sobre exportar usuários especificados ...
. exportando objetos e ações procedurais anteriores ao esquema
. exportando os nomes da biblioteca de função externa para usuário ORACLE_DATA
. exportando sinônimos do tipo PÚBLICO
. exportando sinônimos do tipo privado
. exportando definições de tipos de objeto para usuário ORACLE_DATA
Sobre exportar objetos de ORACLE_DATA ...
. exportando vínculos de banco de dados
. exportando números de seqüência
. exportando definições de cluster
. sobre exportar tabelas de ORACLE_DATA ... via Caminho Convencional ...
. . exportando tabela DRT_FRG 969580 linhas exportadas
. . exportando tabela DRT_IOP 5860 linhas exportadas
. . exportando tabela DRT_ICFG 786 linhas exportadas
. . exportando tabela DRT_JKL 47888 linhas exportadas
. . exportando tabela DRT_INV 85866 linhas exportadas
. . exportando tabela DRT_ETIQ 65456 linhas exportadas
. . exportando tabela DRT_INDPROG 76968 linhas exportadas
.
.
.
Perfeito. Como já dito anteriormente, é recomendável realizar uma exportação completa de banco de dados, seja utilizando o tradicional utilitário de exportação (exp) ou o Datapump Export (expdp)...
C:\>exp system/***** file=fullbackup full=y statistics=none
Export: Release 10.1.0.2.0 - Production on Qua Dez 3 11:10:22 2008
Copyright (c) 1982, 2004, Oracle. All rights reserved.
Conectado a: Oracle Database 10g Express Edition Release 10.2.0.1.0 - Production
Exportação executada no conjunto de caracteres de WE8PC850 e no conjunto de
caracteres de AL16UTF16 NCHAR o servidor usa WE8MSWIN1252 conjunto de caracteres
(conversão de conjunto de caracteres possível)
Sobre exportar o banco de dados inteiro ...
. exportando definições de tablespace
. exportando perfis
. exportando definições de usuário
. exportando funções
. exportando custos de recurso
. exportando definições de segmento de rollback
. exportando vínculos de banco de dados
. exportando números de seqüência
. exportando nomes alternativos de diretórios
. exportando namespaces de contexto
. exportando nomes da biblioteca de função externa
. exportando sinônimos do tipo PÚBLICO
. exportando sinônimos do tipo privado
. exportando definições de tipos de objeto
. exportando objetos e ações procedurais de sistema
. exportando objetos e ações procedurais anteriores ao esquema
. exportando definições de cluster
. sobre exportar tabelas de SYSTEM ... via Caminho Convencional ...
. . exportando tabela DEF$_AQCALL 0 linhas exportadas
. . exportando tabela DEF$_AQERROR 0 linhas exportadas
. . exportando tabela DEF$_CALLDEST 0 linhas exportadas
. . exportando tabela DEF$_DEFAULTDEST 0 linhas exportadas
. . exportando tabela DEF$_DESTINATION 0 linhas exportadas
. . exportando tabela DEF$_ERROR 0 linhas exportadas
. . exportando tabela DEF$_LOB 3 linhas exportadas
. . exportando tabela DEF$_ORIGIN 0 linhas exportadas
. . exportando tabela DEF$_PROPAGATOR 5 linhas exportadas
. . exportando tabela DEF$_PUSHED_TRANSACTIONS 0 linhas exportadas
. . exportando tabela REPCAT$_OBJECT_PARMS 0 linhas exportadas
. . exportando tabela REPCAT$_OBJECT_TYPES 28 linhas exportadas
. . exportando tabela REPCAT$_RESOLUTION 0 linhas exportadas
. . exportando tabela REPCAT$_RESOLUTION_METHOD 19 linhas exportadas
. . exportando tabela REPCAT$_TEMPLATE_TYPES 2 linhas exportadas
. . exportando tabela SQLPLUS_PRODUCT_PROFILE 0 linhas exportadas
. sobre exportar tabelas de OUTLN ... via Caminho Convencional ...
. . exportando tabela OL$ 0 linhas exportadas
. . exportando tabela OL$HINTS 0 linhas exportadas
. . exportando tabela OL$NODES 0 linhas exportadas
. sobre exportar tabelas de TSMSYS ... via Caminho Convencional ...
. . exportando tabela SRS$ 0 linhas exportadas
. sobre exportar tabelas de ANONYMOUS ... via Caminho Convencional ...
. sobre exportar tabelas de HR ... via Caminho Convencional ...
. . exportando tabela COUNTRIES 25 linhas exportadas
. . exportando tabela DEPARTMENTS 27 linhas exportadas
. . exportando tabela EMPLOYEES 107 linhas exportadas
. . exportando tabela JOB_HISTORY 10 linhas exportadas
. . exportando tabela JOBS 19 linhas exportadas
. . exportando tabela LOCATIONS 23 linhas exportadas
. . exportando tabela REGIONS 4 linhas exportadas
.
.
.
No mais, com o cenário mostrado neste artigo, podemos perceber que mesmo para pequenas bases de dados, inclusive que se utilizam do Oracle Databse 10g Express Edition, o desenvolvimento de um plano de backup e recuperação é da maior importância. É lógico que dependendo do caso, um plano adequado de backup e recuperação não tem que ser necessariamente o mais elaborado e complexo ... na verdade, ele precisa ser aquele que irá servir melhor às necessidades de cada negócio. Em geral os tipos de backups dos bancos de dados Oracle se classificam em três categorias simples:
* Backup do sistema operacional (OS)
* Backups gerenciados pelo RMAN (Recovery Manager)
* Backups lógicos
Em resumo, cada tipo de método de backup tem suas próprias vantagens e desvantagens. O processo de criação de uma boa estratégia de backup e recuperação envolve a avaliação dos méritos e problemas desses diferentes tipos de backups, e sua combinação conforme a necessidade para criar um nível aceitável de proteção efetivo.
