Using DBMS_PDB.RECOVER

Hi guys, just passing here to post how you should use DBMS_PDB.RECOVER in order to successfully recover your PDB description XML file if you receive the error ORA-65139: Mismatch between XML metadata file and data file <DATAFILE_PATH> .

To successfully execute this procedure, you must have the description XML file. It’s quite simple when you know exactly what to do. The confusion is that you must point all the PDB’s datafiles excluding the ones from UNDO tablespace. That’s because when you are using a Multitenant Architecture, the UNDO tablespace is used for all pluggable databases. Also, all datafiles should be separated with a comma without any spaces, so it should look like this:

BEGIN
DBMS_PDB.RECOVER(PDB_DESCR_FILE=> ‘/home/oracle/PDB01.xml’, PDB_NAME=>’PDB01′, FILENAMES=> ‘+DATA/PDB01/DATAFILE/sysaux_262_863892639,+DATA/PDB01/DATAFILE/system_261_863892625,
+DATA/PDB01/DATAFILE/users_265_863892763′);
END;
/

After that, you can just execute the statement below, if you don’t want to copy datafiles to a new location:

SQL> CREATE PLUGGABLE DATABASE PDB01 USING ‘/home/oracle/PDB01.xml’ NOCOPY TEMPFILE REUSE;

Quite easy, right?! Yes, but I took some time to use this procedure, so that’s why I’m pointing it right to you. Cya, guys!

Recuperando Banco de Dados com Data Recovery Advisor

Olá, pessoal. Hoje estou blogando sobre a maneira mais fácil de se recuperar um banco de dados single instance e que poucas pessoas conhecem. Obviamente que este processo deve ser executado através do RMAN (o qual muitos DBAs não conhecem muito bem, infelizmente) mas o trunfo deste procedimento é que nem mesmo quem conhece o conceito de recuperação de um banco consegue executá-lo. Ou até mesmo, pode ser utilizado para estudo pois o procedimento gera e explica o processo de recuperação.

Esta técnica funciona apenas em banco single instance e basta você executar os comandos pelo RMAN após ter conectado no banco, claro. Abaixo estão os comandos e uma breve explicação destes:

  • LIST FAILURE: para listar as falhas encontradas no banco;
  • ADVISE FAILURE: para informar o procedimento a ser executada para recuperar o banco;
  • REPAIR FAILURE: executar o procedimento acima e possivelmente efetuar a recuperação do seu banco. Este passo somente poderá ser executado antes do passo anterior.

Agora vamos a prática, no cenário abaixo irei apagar o datafile da tablespace do SYS com o banco aberto e adivinhem só? Pois é, a base travou. Bom, baixei a base com abort e agora irei tentar iniciá-la, obviamente, a mesma não abre pois não acha o datafile apagado:

SQL> startup     
ORACLE instance started.

Total System Global Area  393375744 bytes
Fixed Size                  1345184 bytes
Variable Size             369101152 bytes
Database Buffers           16777216 bytes
Redo Buffers                6152192 bytes
Database mounted.
ORA-01157: cannot identify/lock data file 1 – see DBWR trace file
ORA-01110: data file 1:
‘/u01/app/oracle/oradata/PROD4/datafile/o1_mf_system_9lc3jkwb_.dbf’

Bom, como eu já havia efetuado um backup antes, irei iniciar a recuperação através dos passos pelo RMAN. Primeiramente, irei listar o erro:

$ rman target /

Recovery Manager: Release 11.2.0.3.0 – Production on Wed Jan 7 23:04:26 2015

Copyright (c) 1982, 2011, Oracle and/or its affiliates.  All rights reserved.

connected to target database: PROD4 (DBID=1593456204, not open)

RMAN> list failure;

using target database control file instead of recovery catalog
List of Database Failures
=========================

Failure ID Priority Status    Time Detected Summary
———- ——– ——— ————- ——-
371        CRITICAL OPEN      07-JAN-15     System datafile 1: ‘/u01/app/oracle/oradata/PROD4/datafile/o1_mf_system_9lc3jkwb_.dbf’ is missing
334        CRITICAL OPEN      07-JAN-15     System datafile 1: ‘/u01/app/oracle/oradata/PROD4/datafile/o1_mf_system_9lc3jkwb_.dbf’ needs media recovery

Atentem para as informações do Summay, esta está indicando que o datafile está faltando e precisará de recuperação. Vamos agora solicitar um “conselho” sobre esta falha:

RMAN> advise failure;

List of Database Failures
=========================

Failure ID Priority Status    Time Detected Summary
———- ——– ——— ————- ——-
371        CRITICAL OPEN      07-JAN-15     System datafile 1: ‘/u01/app/oracle/oradata/PROD4/datafile/o1_mf_system_9lc3jkwb_.dbf’ is missing
334        CRITICAL OPEN      07-JAN-15     System datafile 1: ‘/u01/app/oracle/oradata/PROD4/datafile/o1_mf_system_9lc3jkwb_.dbf’ needs media recovery

analyzing automatic repair options; this may take some time
using channel ORA_DISK_1
analyzing automatic repair options complete

Mandatory Manual Actions
========================
no manual actions available

Optional Manual Actions
=======================
1. If file /u01/app/oracle/oradata/PROD4/datafile/o1_mf_system_9lc3jkwb_.dbf was unintentionally renamed or moved, restore it
2. If you restored the wrong version of data file /u01/app/oracle/oradata/PROD4/datafile/o1_mf_system_9lc3jkwb_.dbf, then replace it with the correct one

Automated Repair Options
========================
Option Repair Description
—— ——————
1      Restore database and recover with UNTIL CANCEL option  
  Strategy: The repair includes recovery in NOARCHIVELOG mode with some data loss
  Repair script: /u01/app/oracle/diag/rdbms/prod4/PROD4/hm/reco_1763538049.hm

Percebam que até mesmo um script é gerado para efetuar o restore, abaixo está o conteúdo deste:

$ cat /u01/app/oracle/diag/rdbms/prod4/PROD4/hm/reco_1763538049.hm
   # database restore and recover until cancel
   restore database;
   recover database;
   alter database open resetlogs;

Agora vamos seguir o processo e executar a reparação da base através do repair failure, qual irá executar o script acima. Podemos confirmar isso devido as instruções que o RMAN passa:

RMAN> repair failure;

Strategy: The repair includes recovery in NOARCHIVELOG mode with some data loss
Repair script: /u01/app/oracle/diag/rdbms/prod4/PROD4/hm/reco_2809343255.hm

contents of repair script:
   # database restore and recover until cancel
   restore database;
   recover database;
   alter database open resetlogs;

Do you really want to execute the above repair (enter YES or NO)? YES
executing repair script

Starting restore at 07-JAN-15
using channel ORA_DISK_1

channel ORA_DISK_1: starting datafile backup set restore
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
channel ORA_DISK_1: restoring datafile 00001 to /u01/app/oracle/oradata/PROD4/datafile/o1_mf_system_9lc3jkwb_.dbf
channel ORA_DISK_1: restoring datafile 00002 to /u01/app/oracle/oradata/PROD4/datafile/o1_mf_sysaux_9lc3jl1s_.dbf
channel ORA_DISK_1: restoring datafile 00003 to /u01/app/oracle/oradata/PROD4/datafile/o1_mf_undotbs1_9lc3jl2v_.dbf
channel ORA_DISK_1: restoring datafile 00004 to /u01/app/oracle/oradata/PROD4/datafile/o1_mf_users_9lc3jl4g_.dbf
channel ORA_DISK_1: restoring datafile 00005 to /u01/app/oracle/oradata/PROD4/datafile/o1_mf_example_9lc3n46x_.dbf
channel ORA_DISK_1: reading from backup piece /tmp/FULL_PROD4_09ps5gs6
channel ORA_DISK_1: piece handle=/tmp/FULL_PROD4_09ps5gs6 tag=TAG20150107T224734
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: restore complete, elapsed time: 00:00:25
Finished restore at 07-JAN-15

Starting recover at 07-JAN-15
using channel ORA_DISK_1

starting media recovery

archived log for thread 1 with sequence 1 is already on disk as file /u01/app/oracle/oradata/PROD4/onlinelog/o1_mf_1_9lc3mx1r_.log
RMAN-08187: WARNING: media recovery until SCN 1136263 complete
Finished recover at 07-JAN-15

database opened
repair failure complete

Pronto, simples assim e o nosso banco está operacional novamente! Este procedimento é interessante para facilmente recuperar um banco de dados. Claro que o procedimento de recuperação não funciona se o controlfile foi perdido porém qualquer pessoa conseguiria saber o que está acontecendo com o banco de dados. É isso ai galerinha, ficamos por aqui hoje! Forte abraaaaaaaa!!