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

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...

ORA-28365: wallet is not open - Oracle Data Guard + Oracle TDE

Problema: No meu ambiente de testes usando Oracle Data Guard e com algumas tablespaces com TDE me deparei com o seguinte erro: PR00 (PID:396056): MRP0: Background Media Recovery terminated with error 28365 2024-03-15T03:12:42.419136+00:00 Errors in file /u01/app/oracle/diag/rdbms/thdr/thdr/trace/thdr_pr00_396056.trc: ORA-28365: wallet is not open 2024-03-15T03:12:43.000571+00:00 Recovery interrupted! Recovered data files to a consistent state at change 32232590 Stopping change tracking Solução: Verifiquei a wallet na base de dados standby e estava fechada. set lines 300 col name for a15 col wrl_type for a10 col status for a30 select p.con_id, p.name, p.open_mode, ew.wrl_type, ew.wallet_type, ew.status from v$pdbs p join v$encryption_wallet ew on (ew.con_id = p.con_id) order by p.con_id;     CON_ID NAME            OPEN_MODE  WRL_TYPE   WALLET_TYPE          STATUS ---------- --------------- ---------- --------...

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....