Para melhor visualização, recomendo resolução de no mínimo 1280 x 800 e navegador Mozilla Firefox


segunda-feira, 2 de fevereiro de 2015

Abordando a recuperação de um datafile sem backup através do RMAN e do SQL*Plus

Por Eduardo Legatti

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.

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:

Rjg disse...

Cara vc é show ao cubo!

Eduardo Legatti disse...

Olá Ronei,

Obrigado pela visita! ;-)

Abraços

Legatti

Anônimo disse...

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!!!

Eduardo Legatti disse...

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

Eramirton disse...

Excelente, já conhecia o método de criar o arquivo pelo SO, mas esse é muito melhor.
Parabéns!

Postagens populares