logo
Entre em contato e saiba mais sobre como a DataUnique pode transformar seu negócio.

Fale Conosco

contato@dataunique.com.br
(62) 3932-2512
banner-winthor-sidebar
 

Recovery de Redo Log sem multiplexação

Recovery de Redo Log sem multiplexação

banner-winthor-header

Introdução

Este artigo discute como restaurar o redo log do banco de dados Oracle. Caso o arquivo de redo não esteja acessível por alguma razão, o banco de dados não irá funcionar corretamente.

Redo Logs

Redo logs registra todas as alterações feitas nos datafiles. Cada vez que os dados são alterados no banco de dados, essa alteração é gravada primeiro no registro de redo log online, antes de ser aplicada nos datafiles.

Se um backup de um datafile em algum ponto do tempo e um conjunto completo de redo logs a partir de um ponto para frente estiverem disponíveis, o banco de dados pode reaplicar as alterações registradas nos redo logs, para reconstruir o conteúdo do datafile em qualquer ponto entre o último backup e o final do último registro do redo log. No entanto isto só é possível se o banco estiver com o modo de archive log habilitado.

Os arquivos de redo possui os seguinte status:

UNUSED – Redo log on-line nunca foi gravado. Este é o estado de um redo log que acabou de ser adicionado, ou apenas depois de um RESETLOGS, quando não é o redo log atual.

CURRENT – Log de redo atual. Isto implica que o redo log está ativo. O redo log pode estar aberto ou fechado.

ACTIVE – Log está ativo, mas não é o log atual. É necessário para recuperação de falhas. Pode estar em uso para recuperação de bloco. Pode ou não ser arquivado.

CLEARING – O log está sendo recriado como um log vazio após uma instrução ALTER DATABASE CLEAR LOGFILE. Depois que o log é limpo, o status muda para UNUSED.

CLEARING_CURRENT – O log atual está sendo limpo de um encadeamento fechado. O log pode permanecer nesse status se houver alguma falha no switch, como um erro de E / S que esteja gravando o novo cabeçalho de log.

INACTIVE – O log não é mais necessário para a recuperação da instância. Pode estar em uso para recuperação de mídia. Pode ou não ser arquivado.

Cenário

Banco de dados versão 12.1.0.2 em modo archive log, com redo log sem multiplexação. Foi realizado a deleção de um arquivo de redo não arquivado e inativo com o objetivo de simular uma corrupção.

Analisando o ambiente

tail -n 20 $ORACLE_BASE/diag/rdbms/orcl/ORCL/trace/alert_ORCL.log 

Additional information: 3  
Master background archival failure: 313  
  
Mon Jul 29 16:35:58 2019  
Errors in file /u01/app/oracle/diag/rdbms/orcl/ORCL/trace/ORCL_m000_7142.trc:  
ORA-00313: a abertura falhou para os membros do grupo 2 de log do thread 1  
ORA-00312: thread 2 do log 1 on-line: '/u01/app/oracle/oradata/ORCL/redo02.log'  
ORA-27037: não é possével obter status do arquivo  
Linux-x86_64 Error: 2: No such file or directory  
Additional information: 3  
Mon Jul 29 16:36:58 2019  
Errors in file /u01/app/oracle/diag/rdbms/orcl/ORCL/trace/ORCL_arc2_3190.trc:  
ORA-00313: a abertura falhou para os membros do grupo 2 de log do thread 1  
ORA-00312: thread 2 do log 1 on-line: '/u01/app/oracle/oradata/ORCL/redo02.log'  
ORA-27041: não é possével abrir arquivo  
Linux-x86_64 Error: 2: No such file or directory  
Additional information: 3  
  
ls -1 /u01/app/oracle/oradata/ORCL/redo*.log  
redo01.log  
redo03.log  
  
SQL> set lines 210 pages 1000;  
SQL> select * from v$log;  
  
    GROUP#    THREAD#  SEQUENCE#      BYTES  BLOCKSIZE    MEMBERS ARC STATUS           FIRST_CHANGE# FIRST_TI NEXT_CHANGE# NEXT_TIM     CON_ID  
---------- ---------- ---------- ---------- ---------- ---------- --- ---------------- ------------- -------- ------------ -------- ----------  
         1          1        118   52428800        512          1 NO  CURRENT                1560045 29/07/19   2,8147E+14                   0  
         2          1        116   52428800        512          1 NO  INACTIVE               1559806 29/07/19      1560041 29/07/19          0  
         3          1        117   52428800        512          1 NO  INACTIVE               1560041 29/07/19      1560045 29/07/19          0  

Como o redo log está com status inativo e ainda não foi gerado o archive log, não será possível um recover completo (Media recover) até a sequence 118. Neste caso será realizado uma operação de recover incompleto (também conhecida como Point-in-Time) que é voltar à base a um SCN que não seja último para consertar um erro de usuário ou na falta de um archive.

Recuperação

sqlplus / as sysdba
SQL> shutdown immediate;  
Banco de dados fechado.  
Banco de dados desmontado.  
Instância ORACLE desativada.  
  
SQL> startup mount;  
Instância ORACLE iniciada.  
  
Total System Global Area 1157627904 bytes  
Fixed Size                  2923632 bytes  
Variable Size             436208528 bytes  
Database Buffers          704643072 bytes  
Redo Buffers               13852672 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.  
  
SQL> select * from v$log;  
  
    GROUP#    THREAD#  SEQUENCE#      BYTES  BLOCKSIZE    MEMBERS ARC STATUS           FIRST_CHANGE# FIRST_TI NEXT_CHANGE# NEXT_TIM     CON_ID  
---------- ---------- ---------- ---------- ---------- ---------- --- ---------------- ------------- -------- ------------ -------- ----------  
         1          1          1   52428800        512          1 NO  CURRENT                1561077 29/07/19   2,8147E+14                   0  
         2          1          0   52428800        512          1 YES UNUSED                       0                     0                   0  
         3          1          0   52428800        512          1 YES UNUSED                       0                     0                   0  
  
SQL> select status, open_mode from v$instance,v$database;  
  
STATUS       OPEN_MODE  
------------ --------------------  
OPEN         READ WRITE  

ls -1 /u01/app/oracle/oradata/ORCL/redo*.log  
redo01.log  
redo02.log
redo03.log  

Para evitar este tipo de situação é recomendo que os arquivos de redo logs estejam multiplexados, preferencialmente em discos diferentes. Para garantir que não haja perda de informação em caso de corrupção de um dos arquivos de redo log.

ALTER DATABASE ADD LOGFILE MEMBER '/u01/app/oracle/oradata/ORCL/redo01b.log' TO GROUP 1;  
ALTER DATABASE ADD LOGFILE MEMBER '/u01/app/oracle/oradata/ORCL/redo02b.log' TO GROUP 2;  
ALTER DATABASE ADD LOGFILE MEMBER '/u01/app/oracle/oradata/ORCL/redo03b.log' TO GROUP 3;
Thiago Silva

thiago.silva@dataunique.com.br

Nenhum Comentário

Escreva um Comentário

Comentário
Nome
Email
Website