Pular para o conteúdo principal

Restore #1 Oracle Redo Log Active

Restore #1 Oracle Redo Log Active

Restore é sempre uma situação que você precisa saber o que está fazendo e quase sempre não tem muito tempo para fazer um pesquisa. Então é bom se preparar antes do pior acontecer. 
Então pensei em escrever um série de post com algumas para me ajudar e ajudar outras pessoas a passarem por algumas situações virão.



Imagina que você tem um banco de dados com Redo Log não multiplexado e por algum motivo seu grupo de redo com o status ACTIVE foi corrompido, como faria pra se recuperar dessa falha?



Criando o cenário:

1 - Consulte qual é o seu grupo com status ACTIVE


SQL> select group#,sequence#,members,status From v$log;

    GROUP#  SEQUENCE#    MEMBERS STATUS
---------- ---------- ---------- ----------------
         1          7          1 CURRENT
         2          5          1 INACTIVE
         3          6          1 ACTIVE
 



SQL> select group#,member from v$logfile;

    GROUP# MEMBER
---------- -----------------------------------------------
         3 /u01/app/oracle/oradata/MOPA/redo03.log
         2 /u01/app/oracle/oradata/MOPA/redo02.log
         1 /u01/app/oracle/oradata/MOPA/redo01.log
 

2 - Remova o redo log ativo

SQL> ! rm  /u01/app/oracle/oradata/MOPA/redo03.log
rm: remover arquivo comum “ /u01/app/oracle/oradata/MOPA/redo03.log”? y
 
3 - Verifique seu alerta.

A principio nada vai ser registrado.
Faça um shutdow na base. Se tentar abrir o banco verá que ele irá reportar um erro.



SQL> startup
ORACLE instance started.

Errors in file /u01/app/oracle/diag/rdbms/mopa/MOPA/trace/MOPA_ora_20926.trc:
ORA-00313: a abertura falhou para os membros do grupo 1 de log do thread
ORA-00312: thread 3 do log 1 on-line: ' /u01/app/oracle/oradata/MOPA/redo03.log'



Restore:

1 - Abra o banco de dados em mount


SQL> startup mount;
ORACLE instance started.

Total System Global Area 1577058216 bytes
Fixed Size                  8896424 bytes
Variable Size             503316480 bytes
Database Buffers         1056964608 bytes
Redo Buffers                7880704 bytes
Database mounted.


 2 - Execute uma falsa recuperação incompleta e em seguida abra seu banco com RESETLOGS

SQL> RECOVER DATABASE UNTIL CANCEL;
Media recovery complete.
SQL> ALTER DATABASE OPEN RESETLOGS;
Database altered.

 3 - Após disso verifique que seu banco terá uma nova incarnação.


RMAN> LIST INCARNATION;

using target database control file instead of recovery catalog

List of Database Incarnations
DB Key  Inc Key DB Name  DB ID            STATUS  Reset SCN  Reset Time
------- ------- -------- ---------------- --- ---------- ----------
1       1       MOPA     2559517607       PARENT  1          07-FEB-18
2       2       MOPA     2559517607       PARENT  1477662    16-JAN-20
3       3       MOPA     2559517607       PARENT  1678728    17-JAN-20
4       4       MOPA     2559517607       CURRENT 1680469    17-JAN-20
 

Comentários

Postagens mais visitadas deste blog

Configurando a política de retenção de backups no RMAN

                       Configurando a politica de reten çã o de backups no RMAN        O objetivo deste post é explicar como podemos configurar a reten çã o de backups na poderosa ferramenta de backup do bando de dados Oracle RMAN. Podemos configurar nossa pol í tica tendo por base dois tipos: janela de recupera çã o (recovery window) ou redundãncia (redundancy). Abaixo iremos abordar os dois tipos.       Para identificar qual dos dois tipos o RMAN está usando, use: RMAN> show retention policy; Política baseada em redundância CONFIGURE RETENTION POLICY TO REDUNDANCY 1; Política baseada em janela de recuperação CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 2 DAYS; ·        Política baseada em redund â ncia ( REDUNDANCY )       De uma maneira bem simples e objetiva, o par â metro REDUNDANCY especifica quantos backups full ou incremental level 0 de cada datafile o RMAN vai manter, os demais são considerados obsoletos. Veja o exemplo abaixo

Permissões necessárias para criar triggers no Oracle

Há pouco tempo passei por um problema durante a criação de uma trigger de LOGON na versão 12c do banco de dados Oracle. Estava com alguns problemas em uma aplicação que tinha uma trigger de Logon. A trigger em si era bem simples, vou por o código mais abaixo, o problema é que ela estava criada dentro do usuário SYSTEM. Provavelmente foi a maneira mais fácil e preguiçosa de criar o objeto, uma vez que o SYSTEM já possui todas as permissões necessárias para criação. Porém isso não uma boa prática. Então resolvi tirar do SYSTEM e jogar para o usuário dono dos objetos da aplicação. Quando fui tentar criar o objeto no SCHEMA dono dos objetos da aplicação, recebi um erro com falta de permissões: ORA-01031: insufficient privileges . O erro ocorreu porque estava esquecendo de conceder a role ADMINISTER DATABASE TRIGGER para o usuário. Em resumo, as permissões necessárias para criação de uma trigger: CREATE TRIGGER - para criar uma trigger no seu próprio esquema (SCHEMA) CREATE AN

ORA-01623 ORA-00312 - Removendo redo logs

Após realizar um restore de um ambiente de Oracle RAC para um single instance usando snapshot de storage, tentei recriar os redo logs recebi o seguinte erro durante a exclusão de um grupo de discos. SQL> alter database drop logfile group 2; ORA-01623: o log 2 é o log atual para a instância UOW (thread 1) - não é possível eliminar ORA-00312: thread 2 do log 1 on-line: '+DATA/UOW/ONLINELOG/group_2.1638.1051804433' ORA-00312: thread 2 do log 1 on-line: '+DATA/UOW/ONLINELOG/group_2.981.1051804433' O erro quer dizer que o grupo de redo pertence a outra thread. Quer dizer que ele pertence a outra instância do ambiente RAC. Como no meu caso não precisarei mais dela, basta usar o comando: SAL> alter database disable thread 2; Database altered.   Usei o SQL abaixo para gerar os comandos para excluir os redo logs SQL> select distinct 'alter database drop logfile group '||(group#)||';' from v$log where thread#=2; 'ALTERDATABASEDROPLOGFILEGROUP'||(G