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


domingo, 25 de novembro de 2007

Recuperação no modo NOARCHIVELOG

Por Eduardo Legatti

Olá,

Se você leu e entendeu a diferença entre os dois modos de operação do Oracle descritas no artigo de Agosto/2007 à respeito dos modos ARCHIVELOG e NOARCHIVELOG, então você verá como será possível recuperar um banco de dados no modo NOARCHIVELOG. Devido às chances de recuperação de um banco de dados operando sem o modo de arquivamento ativado serem mínimas ou quase nulas (em um ambiente real), trate este artigo apenas como fonte didática. Por favor, não confunda recuperação com restauração, porque são coisas diferentes.

Agora, em caso de uma falha de mídia, porque as chances de recuperação de um banco de dados operando no modo NOARCHIVELOG são mínimas ou quase nulas? Simples. Pelo fato dos arquivos de registro de redo log online terem uma natureza cíclica, os mesmos não são arquivados durante a operação de alternância de log (log switch). Neste caso, os dados de redo contidos em um grupo podem ser sobregravados a cada operação de alternância de log ocasionando, assim, a perda de dados importantes necessários para recuperação completa do banco de dados. Então, lembre-se de que os registros de redo log online não são arquivados (copiados) e o processo de segundo plano log writer process (LGWR) recicla os registros de redo log online, sobregravando os grupos de registro de redo preenchidos.

Em resumo, quando uma falha de mídia ocorrer, será necessário restaurar um backup de banco de dados fechado (cold backup) válido. No modo NOARCHIVELOG, todos os arquivos deverão ser restaurados, mesmo que apenas um arquivo de dados tenha sido danificado ou perdido. É necessário certificar de ter restaurado todos os arquivos de dados (datafiles) e arquivos de controle (controlfiles). Você poderá restaurar os arquivos de redo log online também, caso tenha feito o backup junto com os controlfiles e datafiles. Lembre-se de que todos os arquivos de banco de dados Oracle deverão estar sincronizados para que o mesmo possa ser aberto.

No caso de um banco de dados operando no modo NOARCHIVELOG, na qual sofreu uma falha de mídia, e que acarretou na perda de um ou mais arquivos de dados, será necessário restaurar apenas os arquivos de dados afetados, isso se nenhum arquivo de redo log online tiver sido sobre-gravado desde o último backup. Neste artigo abordarei especificamente este caso.

Cenário:

  • Existem três grupos de redo log online.
  • Foi feito um backup frio (cold backup) na seqüência de log 3.
  • Foi feita uma carga de dados em um segmento (tabela) pertencente ao tablespace formado pelo arquivo de dados 10.
  • Enquanto o banco de dados estava na seqüência de log 5, o arquivo de dados 10 foi perdido.
Resultado:
  • Como a seqüência de log 3 não foi sobre-gravada, então apenas o arquivo de dados número 10 precisará ser restaurado do backup e recuperado manualmente.
Pronto, então agora vamos ao que interessa.

Irei abrir o banco de dados com a opção de resetlogs apenas para reiniciar novamente a seqüência de logs. Para isso simularei uma recuperação incompleta.

oracle@linux:~> sqlplus "/ as sysdba"

SQL*Plus: Release 9.2.0.4.0 - Production on Qui Nov 22 11:18:29 2007

Copyright (c) 1982, 2002, Oracle Corporation.  All rights reserved.

Conectado a uma instância inativa.

SQL> startup mount
Instância ORACLE iniciada.

Total System Global Area  114365800 bytes
Fixed Size                   451944 bytes
Variable Size              92274688 bytes
Database Buffers           20971520 bytes
Redo Buffers                 667648 bytes
Banco de dados montado.

SQL> recover database until cancel;

Recuperação de mídia concluída.

SQL> alter database open resetlogs;

Banco de dados alterado.

Confirmando que o banco está operando no modo NOARCHIVELOG.


SQL> archive log list
Modo log de banco de dados   Modo Sem Arquivamento
Arquivamento automático      Desativado
Destino de arquivamento      /archive
A seqüência de log on-line mais antiga     0
Seqüência de log atual           1

SQL> select log_mode from v$database;

LOG_MODE
------------
NOARCHIVELOG 

Irei criar um tablespace chamado TBS_RECOVER que será usado para a simulação da recuperação.

SQL> create tablespace tbs_recover
 2 logging
 3 datafile '/u01/oradata/BD1/tbsrecover01.dbf' size 100m
 4 extent management local
 5 segment space management auto;
 6 /

Tablespace criado.
Irei criar um schema de banco de dados que será usado para criar uma tabela com alguns registros.

SQL> create user legatti identified by legatti
 2 default tablespace tbs_recover
 3 quota unlimited on tbs_recover;
 4 /

Usuário criado.

SQL> grant connect,resource to legatti;

Concessão bem-sucedida.
Confirmando o grupo e a seqüência atual de redo log nos arquivos de controle.

SQL> set linesize 1000
SQL> select * from v$log;

    GROUP#    THREAD#  SEQUENCE#      BYTES    MEMBERS ARC STATUS   FIRST_CHANGE# FIRST_TIME
---------- ---------- ---------- ---------- ---------- --- -------- ------------- ----------
         1          1          1    1048576          1 NO  CURRENT        5065706 22/11/2007
         2          1          0    1048576          1 YES UNUSED               0
         3          1          0    1048576          1 YES UNUSED               0

Devido ao fato de eu ter resetado a seqüência de log, irei forçar 2 alternâncias de log afim de se chegar na seqüência 3 como descrito no cenário.

SQL> alter system switch logfile;

Sistema alterado.

SQL> /

Sistema alterado.
Novamente irei confirmar o grupo e a seqüência atual de redo log registrada nos arquivos de controle.

SQL> select * from v$log;

    GROUP#    THREAD#  SEQUENCE#      BYTES    MEMBERS ARC STATUS   FIRST_CHANGE# FIRST_TIME
---------- ---------- ---------- ---------- ---------- --- -------- ------------- ----------
         1          1          1    1048576          1 NO  INACTIVE       5065706 22/11/2007
         2          1          2    1048576          1 NO  INACTIVE       5065883 22/11/2007
         3          1          3    1048576          1 NO  CURRENT        5065885 22/11/2007

SQL> select current_group#,sequence#,checkpoint_change# from v$thread;

CURRENT_GROUP#  SEQUENCE# CHECKPOINT_CHANGE#
-------------- ---------- ------------------
             3          3            5065885

Irei fechar o banco de dados para realizar um backup de todos os arquivos (controlfiles, datafiles e redo log files). Então neste caso, o backup será realizado na seqüência de log 3.

SQL> shutdown
Banco de dados fechado.
Banco de dados desmontado.
Instância ORACLE desativada.
SQL> exit

Desconectado de Oracle9i Enterprise Edition Release 9.2.0.4.0 - Production
With the Partitioning, OLAP and Oracle Data Mining options
JServer Release 9.2.0.4.0 - Production

oracle@linux:~> cp -a /u01/oradata /u01/bkp
Irei abrir o banco de dados para realizar a simulação de uma carga de dados no schema criado anteriormente.

oracle@linux:~> sqlplus "/ as sysdba"

SQL*Plus: Release 9.2.0.4.0 - Production on Qui Nov 22 11:25:52 2007

Copyright (c) 1982, 2002, Oracle Corporation.  All rights reserved.

Conectado a uma instância inativa.

SQL> startup
Instância ORACLE iniciada.

Total System Global Area  114365800 bytes
Fixed Size                   451944 bytes
Variable Size              92274688 bytes
Database Buffers           20971520 bytes
Redo Buffers                 667648 bytes
Banco de dados montado.
Banco de dados aberto.

SQL> connect legatti/legatti;
Conectado.

SQL> create table emp (id number);

Tabela criada.

SQL> begin
 2  for i in 1..100000
 3  loop
 4   insert into emp values (i);
 5  end loop;
 6 end;
/

Procedimento PL/SQL concluído com sucesso.

SQL> commit;

Validação completa.

SQL> select count(*) from emp;

   COUNT(*)
-----------
     100000
Podemos perceber abaixo, realizando uma consulta na view V$LOG, que ocorreu uma alternância de log (log switch) devido à carga de dados realizada na tabela EMP. Agora, o grupo de redo número 2 é o grupo atual e contém a seqüência 5. Neste caso, a seqüências 1 e 2 foram sobregravadas.OBS: apenas aproveitando a oportunidade, vocês podem notar que o STATUS do grupo de redo 1 está definido como ACTIVE o que significa que, em caso de falha de instância, o mesmo será utilizado no processo de recuperação.

SQL> connect "/ as sysdba"
Conectado.

SQL> select * from v$log;

    GROUP#    THREAD#  SEQUENCE#      BYTES    MEMBERS ARC STATUS   FIRST_CHANGE# FIRST_TIME
---------- ---------- ---------- ---------- ---------- --- -------- ------------- ----------
         1          1          4    1048576          1 NO  ACTIVE         5066130 22/11/2007
         2          1          5    1048576          1 NO  CURRENT        5066375 22/11/2007
         3          1          3    1048576          1 NO  INACTIVE       5065885 22/11/2007

SQL> shutdown
Banco de dados fechado.
Banco de dados desmontado.
Instância ORACLE desativada.

SQL> exit

Desconectado de Oracle9i Enterprise Edition Release 9.2.0.4.0 - Production
With the Partitioning, OLAP and Oracle Data Mining options
JServer Release 9.2.0.4.0 - Production
Irei simular uma falha de disco deletando fisicamente o arquivo de dados número 10 que é o datafile pertencente ao tablespace TBS_RECOVER.

oracle@linux:~> rm /u01/oradata/BD1/tbsrecover01.dbf
Após realizar o procedimento acima, vou tentar abrir o banco de dados novamente e você verá que o banco de dados não abrirá porque o arquivo de dados 10 não foi encontrado.

oracle@linux:~> sqlplus "/ as sysdba"

SQL*Plus: Release 9.2.0.4.0 - Production on Qui Nov 22 11:36:13 2007

Copyright (c) 1982, 2002, Oracle Corporation.  All rights reserved.

Conectado a uma instância inativa.

SQL> startup
Instância ORACLE iniciada.

Total System Global Area  114365800 bytes
Fixed Size                   451944 bytes
Variable Size              92274688 bytes
Database Buffers           20971520 bytes
Redo Buffers                 667648 bytes
Banco de dados montado.

ORA-01157: não é possível identificar/bloquear arquivo de dados 10 - consulte
arquivo de análise DBWR
ORA-01110: 10 do arquivo de dados: '/u01/oradata/BD1/tbsrecover01.dbf'

SQL> select * from v$recover_file;

     FILE# ONLINE  ONLINE_ ERROR                               CHANGE# TIME
---------- ------- ------- -------------------------------- ---------- ----------
        10 ONLINE  ONLINE  FILE NOT FOUND                            0 22/11/2007
Neste caso, o banco de dados ficou no estado MOUNT, então para exemplificar, fecharei novamente o banco de dados e restaurarei o arquivo de dados 10 (tbsrecover01.dbf) do backup.

SQL> shutdown
ORA-01109: banco de dados não aberto
Banco de dados desmontado.
Instância ORACLE desativada.

SQL> exit

Desconectado de Oracle9i Enterprise Edition Release 9.2.0.4.0 - Production
With the Partitioning, OLAP and Oracle Data Mining options
JServer Release 9.2.0.4.0 - Production

oracle@linux:~> cp -a /u01/bkp/BD1/tbsrecover01.dbf /u01/oradata/BD1/
Agora com o arquivo de dados restaurado do backup, irei tentar abrir novamente o banco de dados. Você irá perceber que a mensagem de erro mudou de ORA-01157 para ORA-01113, o que significa que ao tentar abrir o banco de dados, o Oracle detectou que as informações de checkpoint contidas no o arquivo de dados 10 não estão sincronizadas com os arquivos de controle.

oracle@linux:~> sqlplus "/ as sysdba"

SQL*Plus: Release 9.2.0.4.0 - Production on Qui Nov 22 11:40:42 2007

Copyright (c) 1982, 2002, Oracle Corporation.  All rights reserved.

Conectado a uma instância inativa.

SQL> startup
Instância ORACLE iniciada.

Total System Global Area  114365800 bytes
Fixed Size                   451944 bytes
Variable Size              92274688 bytes
Database Buffers           20971520 bytes
Redo Buffers                 667648 bytes
Banco de dados montado.

ORA-01113: o arquivo 10 precisa da recuperação de mídia
ORA-01110: 10 do arquivo de dados: '/u01/oradata/BD1/tbsrecover01.dbf'
Verificando a view v$recover_file, que nos mostra quais arquivos precisam de recuperação, podemos ver no campo CHANGE# o número 5065885 que significa o SCN à partir do qual a recuperação deve ser iniciada. Podemos notar também que o número SCN é bem próximo do SCN contido no campo FIRST_CHANGE# da view V$LOG pertencente ao grupo de redo 3 no qual não foi sobregravado durante a carga de dados.

SQL> select * from v$recover_file;

     FILE# ONLINE  ONLINE_ ERROR                               CHANGE# TIME
---------- ------- ------- -------------------------------- ---------- ----------
        10 ONLINE  ONLINE                                      5065889 22/11/2007

Agora irei proceder com a recuperação do arquivo de dados e abrir o banco de dados normalmente.

SQL> recover datafile 10;
Recuperação de mídia concluída.

SQL> alter database open;

Banco de dados alterado.

Irei conectar com o usuário criado anteriormente e verificar se a tabela EMP e os dados inseridos nela foram recuperados com sucesso.

SQL> connect legatti/legatti
Conectado.

SQL> select count(*) from emp;

   COUNT(*)
-----------
     100000

Abaixo, estou mostrando o que foi gravado no arquivo de alerta (alert log file) durante a fase de recuperação.

Thu Nov 22 11:44:29 2007
ALTER DATABASE RECOVER  datafile 10
Thu Nov 22 11:44:29 2007
Media Recovery Datafile: 10
Media Recovery Start
Starting datafile 10 recovery in thread 1 sequence 3
Datafile 10: '/u01/oradata/BD1/tbsrecover01.dbf'
Media Recovery Log
Recovery of Online Redo Log: Thread 1 Group 3 Seq 3 Reading mem 0
  Mem# 0 errs 0: /u01/oradata/BD1/redo02.log
Recovery of Online Redo Log: Thread 1 Group 1 Seq 4 Reading mem 0
  Mem# 0 errs 0: /u01/oradata/BD1/redo03.log
Recovery of Online Redo Log: Thread 1 Group 2 Seq 5 Reading mem 0
  Mem# 0 errs 0: /u01/oradata/BD1/redo01.log
Media Recovery Complete
Completed: ALTER DATABASE RECOVER  datafile 10
Thu Nov 22 11:44:37 2007
alter database open
Thu Nov 22 11:44:37 2007
Thread 1 opened at log sequence 5
  Current log# 1 seq# 5 mem# 0: /u01/oradata/BD1/redo02.log
Successful open of redo thread 1.
Thu Nov 22 11:44:38 2007
SMON: enabling cache recovery
Thu Nov 22 11:44:38 2007
Undo Segment 1 Onlined
Undo Segment 2 Onlined
Undo Segment 3 Onlined
Undo Segment 4 Onlined
Undo Segment 5 Onlined
Undo Segment 6 Onlined
Undo Segment 7 Onlined
Undo Segment 8 Onlined
Undo Segment 9 Onlined
Undo Segment 10 Onlined
Successfully onlined Undo Tablespace 1.
Thu Nov 22 11:44:38 2007
SMON: enabling tx recovery
Thu Nov 22 11:44:38 2007
Database Characterset is WE8ISO8859P1
replication_dependency_tracking turned off (no async multimaster replication found)
Completed: alter database open

Em resumo, diferentemente do que foi demonstrado acima, se você decidir operar um banco de dados no modo NOARCHIVELOG, considere as seguintes vantagens e desvantagens em relação à recuperação:

Vantagens

  • Fácil de executar, pois é necessária apenas uma restauração de todos os arquivos de um backup válido. Os únicos riscos são de natureza operacional como restauração do backup incorreto, sobregravação do backup, não desativação do banco de dados antes da restauração ou criação de backups inválidos (como copiar os arquivos de banco de dados estando com o banco de dados aberto).
  • O tempo necessário para a recuperação é simplesmente o tempo para restaurar todos os arquivos, o que depende do seu hardware e do sistema operacional.
Desvantagens
  • Todos os dados informados pelos usuários desde o último backup serão perdidos e será necessário informá-los manualmente.
  • O banco de dados inteiro precisa ser restaurado à partir do último backup fechado completo (cold backup), mesmo que apenas um arquivo de dados esteja perdido.



Um comentário:

Anônimo disse...

Eduardo,
excelente explicação. Foi muito bom para quem precisar praticar, e pode simular com facilidade.
Marcos

Postagens populares