Olá,
Imagine um cenário na qual em uma manhã de segunda-feira às 08:00, foi criada uma nova tablespace em um banco de dados qualquer, operando no modo ARCHIVELOG. Tabelas foram criadas nessa tablespace, os dados foram inseridos e o sistema começou a funcionar. Imagine que neste ambiente existe uma rotina que executa um backup físico FULL via RMAN todas as noites às 22:00. Agora imagine que às 19:00 neste mesmo dia, o datafile pertencente à essa tablespace foi apagado acidentalmente ou, até mesmo, corrompido. Como não foi realizado nenhum backup desse datafile, já que faltavam ainda 3 horas para o início da rotina de backup, alguém poderia imaginar que todo trabalho realizado no dia estaria perdido.
A boa notícia é que há uma luz no fim do túnel! O objetivo principal deste artigo será demonstrar como podemos recuperar um datafile que não possui backup. Embora se possa utilizar uma técnica em ambientes Linux/Unix para recuperar um arquivo deletado fazendo uso de "file descriptors", irei abordar neste artigo apenas técnicas que envolvam o uso do RMAN e do SQL*Plus para recuperar um arquivo de dados que não possui backup. Vale a pena salientar que para esta técnica funcionar, o banco de dados precisa estar operando no modo ARCHIVELOG e que os archive logs precisam existir desde a criação do datafile.
A boa notícia é que há uma luz no fim do túnel! O objetivo principal deste artigo será demonstrar como podemos recuperar um datafile que não possui backup. Embora se possa utilizar uma técnica em ambientes Linux/Unix para recuperar um arquivo deletado fazendo uso de "file descriptors", irei abordar neste artigo apenas técnicas que envolvam o uso do RMAN e do SQL*Plus para recuperar um arquivo de dados que não possui backup. Vale a pena salientar que para esta técnica funcionar, o banco de dados precisa estar operando no modo ARCHIVELOG e que os archive logs precisam existir desde a criação do datafile.
Segue abaixo o ambiente de simulação na qual existe uma tabela T1 com cerca de 8 milhões de registros e de propriedade do schema SCOTT. A tabela T1 está devidamente criada na tablespace TBS_DATA_01, conforme demonstrado abaixo.
SQL> select owner,table_name,tablespace_name,num_rows
2 from dba_tables
3 where owner='SCOTT';
OWNER TABLE_NAME TABLESPACE_NAME NUM_ROWS
-------------------- -------------------- ----------------------- ----------
SCOTT T1 TBS_DATA_01 8000000
1 linha selecionada.
Em relação a tablespace TBS_DATA_01, foi criado apenas um arquivo de dados conforme demonstrado a seguir.
SQL> select file#,name,status from v$datafile where file#=49;
FILE# NAME STATUS
----- ------------------------------------------------- -------
49 /data/oradata/BD01/tbs_data_01.dbf ONLINE
1 linha selecionada.
Recuperando um datafile sem backup usando o RMAN
Utilizando o RMAN, irei me certificar da existência, ou não, de algum backup relacionado ao datafile pertencente à tablespace TBS_DATA_01.
[oracle@linux1 ~]$ rman target /
Recovery Manager: Release 11.2.0.3.0 - Production on Mon Feb 2 10:19:05 2015
Copyright (c) 1982, 2011, Oracle and/or its affiliates. All rights reserved.
connected to target database: BD01 (DBID=618743438)
RMAN> list backup of tablespace tbs_data_01;
using target database control file instead of recovery catalog
specification does not match any backup in the repository
Confirmado que não há qualquer backup do datafile 49, irei simular a perda do mesmo apagando o arquivo.
[oracle@linux1 ~]$ rm /data/oradata/BD01/tbs_data_01.dbf
Após apagar o arquivo, podemos verificar abaixo que o Oracle já começa a refletir a ausência do mesmo.
SQL> select count(*) from scott.t1;
select count(*) from scott.t1
*
ERRO na linha 1:
ORA-01116: erro ao abrir o arquivo 49 do banco de dados
ORA-01110: 49 do arquivo de dados: '/data/oradata/BD01/tbs_data_01.dbf'
ORA-27041: não é possível abrir arquivo
Linux-x86_64 Error: 2: No such file or directory
Additional information: 3
Para comprovar que o datafile realmente foi apagado, irei colocar o mesmo no estado OFFLINE e imediatamente ONLINE.
SQL> alter database datafile 49 offline;
Banco de dados alterado.
SQL> alter database datafile 49 online;
alter database datafile 49 online
*
ERRO na linha 1:
ORA-01157: não é possível identificar/bloquear arquivo de dados 49
ORA-01110: 49 do arquivo de dados: '/data/oradata/BD01/tbs_data_01.dbf'
SQL> select name,status from v$datafile where file#=49;
NAME STATUS
--------------------------------------------------- -------
/data/oradata/BD01/tbs_data_01.dbf RECOVER
1 linha selecionada.
Consultando novamente a view dinâmica de desempenho V$DATAFILE, podemos verificar que a coluna STATUS apresenta a palavra RECOVER, ou seja, que o arquivo de dados para ficar ONLINE novamente precisa de um restore/recover. Para demonstrar como poderemos recuperar o datafile, irei utilizar o RMAN (Data Recovery Advisor) conforme demonstrado a seguir.
[oracle@linux1 ~]$ rman target /
Recovery Manager: Release 11.2.0.3.0 - Production on Mon Feb 2 10:27:18 2015
Copyright (c) 1982, 2011, Oracle and/or its affiliates. All rights reserved.
connected to target database: BD01 (DBID=618743438)
RMAN> list failure;
using target database control file instead of recovery catalog
List of Database Failures
=========================
Failure ID Priority Status Time Detected Summary
---------- -------- --------- ------------- ------------------------------------------------------------------
44802 HIGH OPEN 02/02/2015 Um ou mais arquivos de dados que não são do sistema estão ausentes
RMAN> advise failure;
List of Database Failures
=========================
Failure ID Priority Status Time Detected Summary
---------- -------- --------- ------------- ------------------------------------------------------------------
44802 HIGH OPEN 02/02/2015 Um ou mais arquivos de dados que não são do sistema estão ausentes
analyzing automatic repair options; this may take some time
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=70 device type=DISK
analyzing automatic repair options complete
Not all specified failures can currently be repaired.
The following failures must be repaired before advise for others can be given.
Failure ID Priority Status Time Detected Summary
---------- -------- --------- ------------- ------------------------------------------------------------------
44802 HIGH OPEN 02/02/2015 Um ou mais arquivos de dados que não são do sistema estão ausentes
Mandatory Manual Actions
========================
no manual actions available
Optional Manual Actions
=======================
1. Se o arquivo /data/oradata/BD01/tbs_data_01.dbf foi renomeado ou movido intencionalmente, restaure-o
Automated Repair Options
========================
Option Repair Description
------ ------------------
1 Restaurar e recuperar o arquivo de dados 49
Strategy: O reparo inclui recuperacão completa de midia sem perda de dados
Repair script: /u01/app/oracle/diag/rdbms/bd01/BD01/hm/reco_4238280548.hm
Após a execução do comando "advise failure", foi criado o arquivo "reco_4238280548.hm" contendo instruções SQL que precisarão ser executadas conforme demonstrado abaixo:
[oracle@linux1 ~]$ cat /u01/app/oracle/diag/rdbms/bd01/BD01/hm/reco_4238280548.hm
# restore and recover datafile
sql 'alter database datafile 49 offline';
restore datafile 49;
recover datafile 49;
sql 'alter database datafile 49 online';
Como orientado pelo RMAN - Data Recovery Advisor, irei executar os comandos a seguir.
RMAN> sql 'alter database datafile 49 offline';
using target database control file instead of recovery catalog
sql statement: alter database datafile 49 offline
RMAN> restore datafile 49;
Starting restore at 02/02/2015
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=34 device type=DISK
creating datafile file number=49 name=/data/oradata/BD01/tbs_data_01.dbf
restore not done; all files read only, offline, or already restored
Finished restore at 02/02/2015
RMAN> recover datafile 49;
Starting recover at 02/02/2015
using channel ORA_DISK_1
starting media recovery
archived log for thread 1 with sequence 7261 is already on disk as file /FRA/BD01/archivelog/2015_02_02/o1_mf_1_7261_bcb23hpc_.arc
archived log for thread 1 with sequence 7262 is already on disk as file /FRA/BD01/archivelog/2015_02_02/o1_mf_1_7262_bcb2402b_.arc
archived log for thread 1 with sequence 7263 is already on disk as file /FRA/BD01/archivelog/2015_02_02/o1_mf_1_7263_bcb2qs11_.arc
archived log for thread 1 with sequence 7264 is already on disk as file /FRA/BD01/archivelog/2015_02_02/o1_mf_1_7264_bcb2qty2_.arc
archived log for thread 1 with sequence 7265 is already on disk as file /FRA/BD01/archivelog/2015_02_02/o1_mf_1_7265_bcb2r1kl_.arc
archived log for thread 1 with sequence 7266 is already on disk as file /FRA/BD01/archivelog/2015_02_02/o1_mf_1_7266_bcb2r3p6_.arc
archived log for thread 1 with sequence 7267 is already on disk as file /FRA/BD01/archivelog/2015_02_02/o1_mf_1_7267_bcb2r5ro_.arc
archived log for thread 1 with sequence 7268 is already on disk as file /FRA/BD01/archivelog/2015_02_02/o1_mf_1_7268_bcb2r7yg_.arc
archived log file name=/FRA/BD01/archivelog/2015_02_02/o1_mf_1_7261_bcb23hpc_.arc thread=1 sequence=7261
archived log file name=/FRA/BD01/archivelog/2015_02_02/o1_mf_1_7262_bcb2402b_.arc thread=1 sequence=7262
archived log file name=/FRA/BD01/archivelog/2015_02_02/o1_mf_1_7263_bcb2qs11_.arc thread=1 sequence=7263
archived log file name=/FRA/BD01/archivelog/2015_02_02/o1_mf_1_7264_bcb2qty2_.arc thread=1 sequence=7264
archived log file name=/FRA/BD01/archivelog/2015_02_02/o1_mf_1_7265_bcb2r1kl_.arc thread=1 sequence=7265
archived log file name=/FRA/BD01/archivelog/2015_02_02/o1_mf_1_7266_bcb2r3p6_.arc thread=1 sequence=7266
media recovery complete, elapsed time: 00:00:05
Finished recover at 02/02/2015
RMAN> sql 'alter database datafile 49 online';
sql statement: alter database datafile 49 online
Pronto. Após a execução das instruções SQL acima foi possível notar que o RMAN criou um novo datafile e aplicou os archive logs da sequência 7261 até 7266. Para comprovar que a recuperação do datafile foi bem sucedida, segue abaixo o resultado de um SELECT COUNT(*) na tabela T1 de propriedade do schema SCOTT.
SQL> select count(*) from scott.t1;
COUNT(*)
----------
8000000
1 linha selecionada.
Recuperando um datafile sem backup usando o SQL*Plus
Agora irei utilizar o SQL*PLus para demonstrar como recuperar o datafile que foi apagado. Para recuperar o arquivo de dados, será necessário basicamente criar um novo datafile com o comando ALTER DATABASE CREATE DATAFILE e aplicar os archive logs necessários utilizando a opção AUTO, conforme demonstração a seguir:
[oracle@linux1 ~]$ sqlplus / as sysdba
SQL*Plus: Release 11.2.0.3.0 Production on Mon Feb 2 10:44:21 2015
Copyright (c) 1982, 2011, Oracle. All rights reserved.
Conectado a:
Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
SQL> alter database datafile 49 offline drop;
Banco de dados alterado.
SQL> alter database create datafile '/data/oradata/BD01/tbs_data_01.dbf';
Banco de dados alterado.
SQL> recover datafile 49;
ORA-00279: alterar 7840579434155 gerado em 01/13/2015 09:52:10 necessario para o thread 1
ORA-00289: sugestão :
/FRA/BD01/archivelog/2015_02_02/o1_mf_1_7261_bcb23hpc_.arc
ORA-00280: alterar 7840579434155 para o thread 1 esta na sequencia #7261
Especificar log: {=nome de arquivo | sugerido | AUTO | CANCEL}
AUTO
ORA-00279: alterar 7840579434734 gerado em 01/13/2015 09:58:39 necessario para o thread 1
ORA-00289: sugestão :
/FRA/BD01/archivelog/2015_02_02/o1_mf_1_7262_bcb2402b_.arc
ORA-00280: alterar 7840579434734 para o thread 1 esta na sequencia #7262
ORA-00279: alterar 7840579434929 gerado em 01/13/2015 09:58:55 necessario para o thread 1
ORA-00289: sugestão :
/FRA/BD01/archivelog/2015_02_02/o1_mf_1_7263_bcb2qs11_.arc
ORA-00280: alterar 7840579434929 para o thread 1 esta na sequencia #7263
ORA-00279: alterar 7840579435636 gerado em 01/13/2015 10:09:29 necessario para o thread 1
ORA-00289: sugestão :
/FRA/BD01/archivelog/2015_02_02/o1_mf_1_7264_bcb2qty2_.arc
ORA-00280: alterar 7840579435636 para o thread 1 esta na sequencia #7264
ORA-00279: alterar 7840579435639 gerado em 01/13/2015 10:09:30 necessario para o thread 1
ORA-00289: sugestão :
/FRA/BD01/archivelog/2015_02_02/o1_mf_1_7265_bcb2r1kl_.arc
ORA-00280: alterar 7840579435639 para o thread 1 esta na sequencia #7265
ORA-00279: alterar 7840579435644 gerado em 01/13/2015 10:09:37 necessario para o thread 1
ORA-00289: sugestão :
/FRA/BD01/archivelog/2015_02_02/o1_mf_1_7266_bcb2r3p6_.arc
ORA-00280: alterar 7840579435644 para o thread 1 esta na sequencia #7266
Log aplicado.
Recuperação de midia concluida.
SQL> alter database datafile 49 online; Banco de dados alterado.
Pronto. Após a execução das instruções SQL acima podemos verificar abaixo, consultado a tabela T1, que o datafile foi recuperado com sucesso.
SQL> select count(*) from scott.t1; COUNT(*) ---------- 8000000 1 linha selecionada.
5 comentários:
Cara vc é show ao cubo!
Olá Ronei,
Obrigado pela visita! ;-)
Abraços
Legatti
Muito bom!
No modo NOARCHIVELOG também é possível, certo? Se deletarmos um arquivo (via S.0) e logo após percebermos sua exclusão, é possível entrar no rman e restaurar o arquivo deletado. O Oracle utiliza os redos para isso? Por quanto tempo ele guarda estas informações? Quando não é possível mais restaurar o arquivo?
Abs e sucesso!!!
Olá Anônimo,
No modo ARCHIVELOG, se você tiver um datafile que foi deletado e não tiver nenhum backup, então você terá que ter todos os archivelogs desde a criação do arquivo. No caso do banco de dados operando no modo NOARCHIVELOG, os redo logs são sobrescritos a cada alternância de log, ou seja, se você perder um datafile que foi criado a 2 minutos atrás e o redo log não foi sobrescrito, então existe uma grande chance do mesmo ser recuperado com essa técnica.
para mais informações sobre os modos ARCHIVELOG e NOARCHIVELOG acesse o artigo abaixo.
http://eduardolegatti.blogspot.com.br/2007/08/como-se-precaver-da-perda-de-dados.html
Obrigado pela visita!
Abraços,
Legatti
Excelente, já conhecia o método de criar o arquivo pelo SO, mas esse é muito melhor.
Parabéns!
Postar um comentário