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

Anônimo disse…
Best m88 casino sites【WG】best m88 casino sites
m88 casino sites. The list of m88 casino sites is as happyluke follows: 제왕카지노 Casino m88 Bonuses, Mobile Casino, Roulette, Slots, Poker, Slot, Video Poker,

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