Oracle Database 12c, O que acontece em um CDB quando um PDB tem ser recuperado

Por Joel Pérez , Mahir M. Quluzade e Rodrigo Mufalani
Postado em Agosto 2014

Introducción
Neste artigo nós queremos responder a questão: O que acontece durante a inicialização de um CDB se um dos PDB’s tiver com problemas de mídia (precisa de recover)?

Visão geral da arquitetura Multitenant

Oracle Multitenant é uma nova arquitetura do Oracle Database 12c Enterprise Edition que ajuda aos clientes a reduzir custos de TI simplificando a consolidação, provisionamento, upgrades e mais. Isso é suportado pela noa arquitetura que permite um container database (CDB) ter um ou muitos pluggable databases (PDBs). A quantidade de PDBs em um único CDB compartilha memória e background processes, deixando você operar muito mais PDBs em uma plataforma espefícica do que você pode com databases únicos na arquitetura antiga.  Este é o mesmo benefício que uma consolidação baseada em schemas trás. Mas há barreiras significantes para adaptar consolidação baseada em schemas, e isso causa prpoblemas de operação. A nova arquitetura remove essas barreriras e problemas de operação.

A arquitetura Multitenant preenche completamente outras opções, incluindo Oracle Real Application Clusters (RAC) e Oracle Active Data Guard. Um database existente pode adaptado simplesmente, sem mudanças , como um pluggable database , e não há necessidade de qualquer outra mudança em outra camada de aplicação.

Um PDB pode ser desplugado de um CDB e plugado em outro. Alternativamente, você pode clonar um, no mesmo CDB, ou de um CDB para outro. Estas operações, juntas com criação de um pluggable database, são feitas com novos comandos SQL e levam alguns segundos. Consolidando um banco de dados existente como pluggable databases, simplifica a administração, que pode ser feita como um todo.

O tempo investido e os esforços para aplicar patches em um CDB resulta em aplicar patches em todos os pluggable databases. Para aplicar patch em um database específico, você simplesmente pode desplugar e plugar este em uma versão diferente do Oracle Database software, já com patch aplicado.

Oracle Database 12c Resource Manager é uma funcionalidade estendida que instantâneamente controla a competição por recursos entre os pluggable databases em um container database.

Muitos database em um servidor
Antes do Oracle Database 12c , a Oracle recomendava: somente um database armazenado em um servidor. Depois do 12c nós podemos usar multiplos pluggable databases em um único container database em um único servidor.

Agora questões emergem:
O que acontece em um CDB quando um dos PDBs tem um problema de mídia?
Como este problema de mídia afeta outros PDB’s ou o CDB?

Neste artigo em nosso ambiente de testes prmcdb é um Container Database e tem dois Pluggable databases neste CDB: prmpdb01, prmpdb02

[oracle@oel62-ora12c /]$ export ORACLE_SID=prmcdb 
[oracle@oel62-ora12c /]$ sqlplus / as sysdba 
 
SQL*Plus: Release 12.1.0.1.0 Production on Wed Feb 12 12:53:16 2014
 
Copyright (c) 1982, 2013, Oracle.  All rights reserved.
 
Connected to:
Oracle Database 12c Enterprise Edition Release 12.1.0.1.0 - 64bit Production
With the Partitioning, OLAP, Advanced Analytics and Real Application Testing options
 
SQL> select con_id, cdb, name, open_mode from v$database; 
 
CON_ID  CDB NAME      OPEN_MODE
------  --- --------- --------------------
     0  YES PRMCDB    READ WRITE
 
SQL> select con_id, name, open_mode from v$pdbs;     
 
CON_ID  NAME               OPEN_MODE
------  ------------------ ----------
     2  PDB$SEED           READ ONLY
     3  PRMPDB01           READ WRITE
     4  PRMPDB02           READ WRITE
 
SQL> select file#, name from v$datafile; 
 
FILE#  NAME
-----  --------------------------------------------------------
  1    /u01/app/oracle/oradata/prmcdb/system01.dbf
  3    /u01/app/oracle/oradata/prmcdb/sysaux01.dbf
  4    /u01/app/oracle/oradata/prmcdb/undotbs01.dbf
  5    /u01/app/oracle/oradata/prmcdb/pdbseed/system01.dbf
  6    /u01/app/oracle/oradata/prmcdb/users01.dbf
  7    /u01/app/oracle/oradata/prmcdb/pdbseed/sysaux01.dbf
  8    /u01/app/oracle/oradata/prmcdb/prmpdb01/system01.dbf
  9    /u01/app/oracle/oradata/prmcdb/prmpdb01/sysaux01.dbf
 10    /u01/app/oracle/oradata/prmcdb/prmpdb01/prmpdb01_users01.dbf
 11    /u01/app/oracle/oradata/prmcdb/prmpdb02/system01.dbf
 12    /u01/app/oracle/oradata/prmcdb/prmpdb02/sysaux01.dbf
 13    /u01/app/oracle/oradata/prmcdb/prmpdb02/prmpdb02_users01.dbf
 
SQL> select file#, status, error from v$datafile_header; 
 
FILE#  STATUS     ERROR
-----  ---------  ---------------------------------------------
  1    ONLINE
  3    ONLINE
  4    ONLINE
  5    ONLINE
  6    ONLINE
  7    ONLINE
  8    ONLINE
  9    ONLINE
 10    ONLINE
 11    ONLINE
 12    ONLINE
 13    ONLINE
 
12 rows selected.
 
SQL> select action_time,action,version,bundle_series,comments from dba_registry_history; 
 
ACTION_TIME                       ACTION  VERSION    BUNDLE_SERIES    COMMENTS
--------------------------------  ------- ---------  ---------------  ---------------
24-MAY-13 01.20.05.485655000 PM   APPLY   12.1.0.1   PSU      Patchset 12.1.0.0.0
08-JUL-13 04.12.17.807394000 PM   APPLY   12.1.0.1   PSU      Patchset 12.1.0.0.0


Nota:
Como você pode ver pela view dba_registery_history nosso database não teve nehum patch aplicado ainda.

Cenário:
Nós iremos remover um datafule de um dos pluggable database com um comando do sistema operacional e iremos reiniciar o container database. Como você sabe, quando inicializamos um container database, os pluggable databases não são abertos automaticamente.  Nós devemos usar o comando SQL alter pluggable database <pluggable database name> open; ou alter pluggable database all open; Antes de tudo fizemos um backup full do Container Database com o Recover Manager (RMAN):

[oracle@oel62-ora12c /]$ rman target / 
Recovery Manager: Release 12.1.0.1.0 - Production on Wed Feb 12 12:52:32 2014
Copyright (c) 1982, 2013, Oracle and/or its affiliates.  All rights reserved.
connected to target database: PRMCDB (DBID=2504197888)
 
RMAN> backup database plus archivelog delete all input;
 
Starting backup at 12-FEB-14
current log archived
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
 
...
 
Finished backup at 12-FEB-14
 
Starting Control File and SPFILE Autobackup at 12-FEB-14
piece handle=/u01/app/oracle/fra/PRMCDB/autobackup/2014_02_12/o1_mf_s_839336238_9hpfvkm7_.bkp comment=NONE
Finished Control File and SPFILE Autobackup at 12-FEB-14


Agora Irei remver um datafile do Pluggable Database prmpdb02.

SQL> select con_id, name, open_mode from v$pdbs;     
 
CON_ID   NAME          OPEN_MODE
------   ------------  ----------
  2      PDB$SEED      READ ONLY
  3      PRMPDB01      READ WRITE
  4      PRMPDB02      READ WRITE
 
SQL> select file#, name from v$datafile; 
 
FILE#    NAME
-----    -----------------------------------------------------
  1      /u01/app/oracle/oradata/prmcdb/system01.dbf
  3      /u01/app/oracle/oradata/prmcdb/sysaux01.dbf
  4      /u01/app/oracle/oradata/prmcdb/undotbs01.dbf
  5      /u01/app/oracle/oradata/prmcdb/pdbseed/system01.dbf
  6      /u01/app/oracle/oradata/prmcdb/users01.dbf
  7      /u01/app/oracle/oradata/prmcdb/pdbseed/sysaux01.dbf
  8      /u01/app/oracle/oradata/prmcdb/prmpdb01/system01.dbf
  9      /u01/app/oracle/oradata/prmcdb/prmpdb01/sysaux01.dbf
 10      /u01/app/oracle/oradata/prmcdb/prmpdb01/prmpdb01_users01.dbf
 11      /u01/app/oracle/oradata/prmcdb/prmpdb02/system01.dbf
 12      /u01/app/oracle/oradata/prmcdb/prmpdb02/sysaux01.dbf
 13      /u01/app/oracle/oradata/prmcdb/prmpdb02/prmpdb02_users01.dbf
 
SQL> ! rm –fr /u01/app/oracle/oradata/prmcdb/prmpdb02/prmpdb02_users01.dbf
 
SQL> shutdown immediate;
ORA-03113: end-of-file on communication channel
 
SQL> exit
 
Disconnected from Oracle Database 12c Enterprise Edition Release 12.1.0.1.0 - 64bit Production
With the Partitioning, OLAP, Advanced Analytics and Real Application Testing options

Como você vê, nós precisamos inicializar o Container Database:

[oracle@oel62-ora12c /]$ sqlplus "/ as sysdba"
 
SQL*Plus: Release 12.1.0.1.0 Production on Wed Feb 12 13:52:32 2014
 
Copyright (c) 1982, 2013, Oracle.  All rights reserved.
Connected to an idle instance.
 
SQL> startup
ORACLE instance started.
 
Total System Global Area 801701888 bytes
Fixed Size        2293496 bytes
Variable Size     377487624 bytes
Database Buffers  419430400 bytes
Redo Buffers      2490368 bytes
Database mounted.
ORA-01157: cannot identify/lock data file 13 - see DBWR trace file
ORA-01110: data file 13: '/u01/app/oracle/oradata/prmcdb/prmpdb02/prmpdb02_users01.dbf'
 

O que ocorre? Container Database não está aberto Não, o database não está aberto, por causa do datafile 13  que não foi encontrado. Sim, nós podemos abrir o container database colocando este datafile offline, então podemos abrir o CDB and podemos abrir os outros PDBs. Por um outro lado, podemos restaurar e recuperar o datafile antes de abrir os outros databases. Eu restaurei o datafile removido e abri todos os PDBs novamente.

Se você aplicar o Patch 17552800 (12.1.0.1.2 Database Patch Set Update released: January 14, 2014), não irá conhecer este problema, CDB irá abrir normalmente.  Quando for abrir todos os PDBs, o CDB irá pular a abertura do PDB com problemas e irá abrir os demais.

Você pode fazer download deste PSU do support.oracle.com.

Patch
Nós baixamos e aplicamos este patch .

SQL> select action_time,action,version,bundle_series,comments from dba_registry_history; 
 
ACTION_TIME                       ACTION   VERSION   BUNDLE_SERIES  COMMENTS
--------------------------------  ------- ---------  ------------- ---------------
24-MAY-13 01.20.05.485655000 PM   APPLY   12.1.0.1   PSU      Patchset 12.1.0.0.0
08-JUL-13 04.12.17.807394000 PM   APPLY   12.1.0.1   PSU      Patchset 12.1.0.0.0
12-FEB-14 09.48.05.383369000 AM   APPLY   12.1.0.1   PSU      PSU 12.1.0.1.2
 
SQL> select * from dba_registry_sqlpatch;
 
PATCH_ID ACTION STATUS ACTION_TIME DESCRIPTION LOGFILE
17552800 APPLY SUCCESS 12-FEB-14 09.49.00.559171000 AM bundle:PSU 
/u01/app/oracle/product/12.1.0/dbhome/sqlpatch/17552800/17552800_apply_PRMCDB_CDBROOT_2014Feb12_09_47_49.log


Nós backupeamos nosso database e tentamos mais uma vez reproduzir o mesmo problema.

SQL> ! rm -fr /u01/app/oracle/oradata/prmcdb/prmpdb02/prmpdb02_users01.dbf
 
SQL> shut immediate;
Database closed.
Database dismounted.
ORACLE instance shut down.
 
SQL> startup
ORACLE instance started.
 
Total System Global Area 801701888 bytes
Fixed Size      2293496 bytes
Variable Size    377487624 bytes
Database Buffers   419430400 bytes
Redo Buffers      2490368 bytes
Database mounted.
Database opened.


Agora o Container Database abriu sem qualquer erro. Agora irei abrir todos os Pluggable Databases. 

SQL> alter pluggable database all open;
alter pluggable database all open
*
ERROR at line 1:
ORA-01157: cannot identify/lock data file  - see DBWR trace file
 
SQL> select name, open_mode from v$pdbs;
 
NAME          OPEN_MODE
------------- ----------
PDB$SEED      READ ONLY
PRMPDB01      READ WRITE
PRMPDB02      MOUNTED
 
SQL> select file#, status, error from  v$datafile_header;
 
FILE#   STATUS    ERROR
-----   --------  ---------------------------------------
  1     ONLINE
  3     ONLINE
  4     ONLINE
  5     ONLINE
  6     ONLINE
  7     ONLINE
  8     ONLINE
  9     ONLINE
 10     ONLINE
 11     ONLINE
 12     ONLINE
 13     ONLINE    FILE NOT FOUND
 
12 rows selected.


Eu peguei o erro, mas outro pluggable database pode ser aberto  e agora o alert log mostra:

alter pluggable database all open

Wed Feb 12 15:11:15 2014
Errors in file /u01/app/oracle/diag/rdbms/prmcdb/prmcdb/trace/prmcdb_dbw0_11432.trc:
ORA-01157: cannot identify/lock data file 13 - see DBWR trace file
ORA-01110: data file 13: '/u01/app/oracle/oradata/prmcdb/prmpdb02/prmpdb02_users01.dbf'
ORA-27037: unable to obtain file status
Linux-x86_64 Error: 2: No such file or directory
Additional information: 3

Wed Feb 12 15:11:15 2014
Pdb PRMPDB02 hit error 1157 during open read write and will be closed.
ALTER SYSTEM: Flushing buffer cache inst=0 container=4 local

Wed Feb 12 15:11:15 2014
Errors in file /u01/app/oracle/diag/rdbms/prmcdb/prmcdb/trace/prmcdb_p001_11482.trc:
ORA-01157: cannot identify/lock data file 13 - see DBWR trace file
ORA-01110: data file 13: '/u01/app/oracle/oradata/prmcdb/prmpdb02/prmpdb02_users01.dbf'

Wed Feb 12 15:11:18 2014
Due to limited space in shared pool (need 6094848 bytes, have 3981120 bytes), 
limiting Resource Manager entities from 2048 to 32
Opening pdb PRMPDB01 (3) with no Resource Manager plan active
Pluggable database PRMPDB01 opened read write
ORA-1157 signalled during: alter pluggable database all open...

Wed Feb 12 15:11:41 2014
Shared IO Pool defaulting to 24MB


Sim, outrso Pluggable Databases foram abertos normalmente. CDB pulou a abertura do prmdb02 (cujo um dos seus datafile não foi econtrado).

Nós podemos restaurar o Pluggable Database com o RMAN:

[oracle@oel62-ora12c ~]$ export ORACLE_SID=prmcdb
[oracle@oel62-ora12c ~]$ rman target / 
 
Recovery Manager: Release 12.1.0.1.0 - Production on Wed Feb 12 15:26:42 2014
 
Copyright (c) 1982, 2013, Oracle and/or its affiliates.  All rights reserved.
connected to target database: PRMCDB (DBID=2504197888)
 
RMAN> restore pluggable database prmpdb02;
 
Starting restore at 12-FEB-14
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=44 device type=DISK
 
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 00011 to /u01/app/oracle/oradata/prmcdb/prmpdb02/system01.dbf
channel ORA_DISK_1: restoring datafile 00012 to /u01/app/oracle/oradata/prmcdb/prmpdb02/sysaux01.dbf
channel ORA_DISK_1: restoring datafile 00013 to /u01/app/oracle/oradata/prmcdb/prmpdb02/prmpdb02_users01.dbf
channel ORA_DISK_1: reading from backup piece /u01/app/oracle/fra/PRMCDB/F231EDEC22372112E043AA38A8C01F0B/
backupset/2014_02_12/o1_mf_nnndf_TAG20140212T125307_9hpfs0td_.bkp
channel ORA_DISK_1: piece handle=/u01/app/oracle/fra/PRMCDB/F231EDEC22372112E043AA38A8C01F0B/
backupset/2014_02_12/o1_mf_nnndf_TAG20140212T125307_9hpfs0td_.bkp tag=TAG20140212T125307
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: restore complete, elapsed time: 00:00:25
Finished restore at 12-FEB-14
 
RMAN> recover pluggable database prmpdb02;
 
Starting recover at 12-FEB-14
using channel ORA_DISK_1
 
starting media recovery
media recovery complete, elapsed time: 00:00:09
 
Finished recover at 12-FEB-14
 
RMAN> alter pluggable database prmpdb02 open;
 
Statement processed
 
RMAN> select name, open_mode from v$pdbs;
 
NAME                           OPEN_MODE 
------------------------------ ----------
PDB$SEED                       READ ONLY 
PRMPDB01                       READ WRITE
PRMPDB02                       READ WRITE



Conclusão

Como podemos ver, depois de aplicado o PSU1, um problema de mídia em um PDB não afeta qualquer outro PDB. Isso quer dizer que quando usamos Pluggable Databases para diferentes aplicações, um problema em um PDB não vai afetar outras aplicações em outros PDBs.

Referência:
http://docs.oracle.com/cd/E16655_01/server.121/e17633/cdbovrvw.htm#CNCPT89234


Joel é um DBA expert com mais de 12 anos de experiência, especializado nas áreas de bases de dados com especial ênfase em soluções de alta disponibilidade (RAC, Dataguard, e outros). É um palestrante habitual em eventos de Oracle como: OTN LAD TOUR e outros. É o primeiro latino-americano a ser nomeado "OTN Expert " no ano de 2003 e é Oracle ACE Director. Durante estes anos, Joel trabalhou como consultor senior em um grande número de empresas e clientes em diversos países: Venezuela, Panama, Costa Rica, Dominican Rep., Haiti, Nicaragua, Guatemala, Colombia, Honduras, Ecuador, Mexico, India, Italy, France.

Mahir é um DBA Senior com mais de 10 anos de experiência no Oracle Database com foco especial em Alta disponibilidade e soluções de Recuperação contra desastres (RAC, Data Guard, RMAN,…). Atualmente trabalha para o Central Bank of the Republic of Azerbaijan. Ele é um Oracle Certified Professional DBA. Mahir é palestrante do Azerbaijan Oracle User Group (AZEROUG) e também é blogger.

Mufalani é um DBA Sr. com mais de 10 anos de experiência, começou com o Oracle 8i, mas teve a oportunidade de dar suporte a Oracle 7.3.4 em diante. É especialista em banco de dados Oracle com foco principal em Performance &Tuning e RAC. É palestrante em eventos de Oracle como: OTN LAD TOUR e outros. Atualmente trabalha como consultor diversas empresas no segmento de variados ramos como: Educação, Saúde, Tecnologia, Seguros e etc. Foi o terceiro Oracle ACE a ser nomeado no Brasil e é OCP DBA nas versões 10g e 11g. Siga Mufalani em seu blog ou no twitter @mufalani.