Pular para o conteúdo principal

Restore #5 - Restore Controlfiles sem backup RMAN

Restore #5 - Restore Controlfiles sem backup RMAN


Imagine que você pedeu todos os seus controlfiles e não tem backup RMAN nem backup as TRACE. Usaremos aqui o SNAPSHOT CONTROLFILE para o restore. 


Criando cenário:

1 - Verifique onde estão seus controlfiles e SNAPSHOT CONTROLFILE

SQL> SHOW PARAMETER CONTROL
  

RMAN> SHOW ALL;

using target database control file instead of recovery catalog
RMAN configuration parameters for database with db_unique_name TESTE are:
CONFIGURE RETENTION POLICY TO REDUNDANCY 1; # default
.
.
.
CONFIGURE SNAPSHOT CONTROLFILE NAME TO '/u01/app/oracle/product/18.3.0/dbhome_1/dbs/snapcf_TESTE.f'; # default
 
 
2 - Simule uma corrupção nos seus controlfiles. Em seguida, acompanhe o log.


echo "Thiago Castro" > /u01/app/oracle/oradata/TESTE/control01.ctl
echo "Thiago Castro" > /u01/app/oracle/oradata/TESTE/control02.ctl
 
3 - Acompanhe o alert do banco. Nesse ponto os erros já devem estar aparecendo e provavelmente sua base irá ficar off line.


Restore:

1 - Copie o SNAPSHOT CONTROLE para o local dos CONROLFILE originais.


 
[oracle@teste backup]$ cp /u01/app/oracle/product/18.3.0/dbhome_1/dbs/snapcf_TESTE.f /u01/app/oracle/oradata/TESTE/control01.ctl
[oracle@teste backup]$ cp /u01/app/oracle/product/18.3.0/dbhome_1/dbs/snapcf_TESTE.f /u01/app/oracle/oradata/TESTE/control02.ctl


2 - Verifique a localização dos seus redos e o status. Você vai precisar passar como parâmetro o redo que estava como CURRENT no momento em que a instância caiu.

SQL> SELECT * FROM V$LOG;       
SQL> SELECT * FROM V$LOGFILE;


3 - Execute a falsa recuperação incompleta (Incomplete Recovery)

SQL> RECOVER DATABASE USING BACKUP CONTROLFILE UNTIL CANCEL;

Especifique o log que estava como CURRENT no momento da queda.

Especificar log: {=nome de arquivo | sugerido | AUTO | CANCEL}
/u01/app/oracle/oradata/TESTE/onlinelog/o1_mf_1_h2pffglc_.log
Log aplicado.


4 - Abra o banco com OPEN RESETLOGS

SQL> ALTER DATABASE OPEN RESETLOGS;


Comentários

Postar um comentário

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 â met...
Postar um comentário
Leia mais

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...
Postar um comentário
Leia mais

Oracleasm Deletedisk - Unable to open device or resource busy failed Unable to clear disk

Após a migração de storages utilizando Oracle ASM em um ambiente, precisei remover os discos que não estavam mais sendo utilizados. Porém quando fui utilizar o deletedisk no oracleasm recebi o seguinte erro: # oracleasm deletedisk -v HITACHI33 Clearing disk header: oracleasm-write-label: Unable to open device "/dev/oracleasm/disks/HITACHI33": Device or resource busy failed Unable to clear disk "HITACHI33" Fiz a verificação para ver ser o disco ainda estava em uso, mas não obtive nenhum retorno: # fuser /dev/oracleasm/disks/HITACHI33 # lsof /dev/oracleasm/disks/HITACHI33 Então lendo alguns posts e artigos vi que o problema poderia estar relacionado ao multipath do sistema operacional. Então utilizei o -f para realizar um flush, mas recebi a mensagem abaixo: # multipath -f /dev/oracleasm/disks/HITACHI33 Jun 22 08:43:21 | must provide a map name to remove Utilizei o comando do ASM para verificar o mapeamento do disco....
Postar um comentário
Leia mais