Oracle Database 12c: ¿Que sucede en un CDB cuando uno de los PDB obtiene un problema?

Por Joel Pérez , Mahir M. Quluzade & Bruno Nuñez
Publicado en Agosto 2014

INTRODUCCIÓN:

En este articulo responderemos la siguiente pregunta: 

¿Que sucede durante la inicialización de un CDB si uno de los PDB tiene un problema?

Vision General de Arquitectura Multitenant

Oracle Multitenant es una nueva arquitectura para Oracle Database 12c Enterprise Edition que ayuda a los clientes a reducir los costos de IT mediante la simplificación de la consolidación, aprovisionamiento, actualizaciones y más. Todo esto es soportado por una nueva arquitectura que permite que un container database (CDB) mantenga muchos pluggable databases (PDBs). Muchos PDBs en un solo CDB comparten sus procesos de background y de memoria, permitiendo asi operar muchos más PDBs en una plataforma especial, logrando la singularización de bases de datos que utilizan la arquitectura antigua. Este es el mismo beneficio que ofrece la consolidación basada en esquemas. Pero hay barreras significativas en la adopción de consolidación basado en esquemas, estas causan problemas de funcionamiento en curso. La nueva arquitectura elimina estas barreras de adopción y problemas de funcionamiento.

La Arquitectura Multitenant complementa plenamente otras soluciones incluyendo Oracle Real Application Clusters (RAC) and Oracle Active Data Guard. Una base de datos existente puede ser simplemente adoptada sin cambios, como un pluggable database,  no necesitandose cambios a niveles de aplicación.

Un  PDB puede ser desconectado desde un container database y conectado a otro. Alternativamente se puede clonar una PDB en el mismo container database, o desde un container database a otro. Estas operaciones junto con la creación de un pluggable database, se hacen con nuevos comandos SQL, tomando sólo unos segundos. Mediante la consolidación de las base de datos existentes  los administradores pueden gestionar muchas bases de datos como si fuese una sola.

Los PDB poseerán la versión de base datos del container por lo tanto.. al aplicar el patch al CBD, el alcance de este se extiende hasta sus PDB. Si se desea tener una sola PDB en una versión diversa del CBD en el cual se encuentre. El procedimiento estará basado en crear otro CBD con la versión diversa deseada y proceder al movimiento de la PDB del antiguo CDB al nuevo CBD.

Oracle Database 12c Resource Manager, se extiende con una funcionalidad específica para controlar instantáneamente la competencia entre los pluggable databases en un container database.

Muchas bases de datos en un servidor

Antes de Oracle Database 12c, Oracle recomendaba tener solo una base de datos en un servidor. Posterior a 12c se pueden usar múltiples pluggable databases en un container database en un solo servidor.

Ahora surge preguntas:

¿Que sucede en un CDB, cuando uno de los PDB tiene un problema?

¿Como afectara el problema de un PDB a otros PDBs o CDB?

En este artículo nuestro entorno de prueba prmcdb es un Container Database y tiene dos Pluggable databases en un 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

Note:  Como se puede ver en el dba_registry_history  nuestra base de datos no ha sido objeto de la aplicación de patch aún.

Escenario:

Procederemos a eliminar un datafile de un pluggable database con comandos del sistema operativo y reiniciaremos el container database. Cuando iniciamos el container database los pluggable database no son iniciados automáticamente. Debemos utilizar alter pluggable database <nombre pluggable database> open; o alter pluggable database all open; Comandos SQL.

Antes de todo obtenemos un full backup del Container Database con 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


[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

Procederemos a remover  un datafile del 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

Tal como se puede observar, nosotros necesitamos iniciar el 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'

¿Que sucede? ¿El Container Database no se abre? Ninguna base de datos se abre, porque el datafile 13 no lo encuentra. Si podemos abrir el container database con este datafile offline, entonces podemos abrir el CDB y también podemos abrir los otros PDBs. De lo contrario podemos restaurar y recuperar este datafile antes de abrir las base de datos. Restaurar datafile borrado y abrir todos los PDBs nuevamente.

Si aplica parche 17552800 (12.1.0.1.2 Database Patch Set lanzamiento de la actualización: Enero 14, 2014), no se encontrara con tal problema, el CDB se abrirá normalmente.

Puedes descargar el PSU1 desde support.oracle.com.

Aplicando el 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

La BBDD se encuentra respaldad y volveremos al escenario nuevamente.



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.

Ahora el Container Database abre sin ningún error.  Ahora iniciaremos todos los 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.

Un error es obtenido pero otro las otras pluggable database se iniciaron perfectamente,  ahora el alert log muestra lo siguiente:



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

Si, otros Pluggable Databases abrieron con normalidad. La CDB se saltó la PDB prmdb02 la cual posee el datafile que no se encuentra). Podemos restaurar el pluggable database con 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

Conclusión:

Como se puede ver, despues de aplicar el PSU1, un posible problema en el inicio de una PDB no llega a afectar a las otras PDB.  

Como siempre.. esperamos que el articulo sea de agrado y utilidad.

Nos vemos en los próximos artículos. 

Joel es un experto DBA con más de 12 años de experiencia, especializado en bases de datos con especial énfasis en la soluciones de alta disponibilidad (RAC, Data Guard, y otras). Es un conferencista habitual en eventos de Oracle como: OTN LAD TOUR y otros. Consultor Internacional con trabajos en más de 20 países alrededor del mundo. Fue el primer latinoamericano en ser nombrado "Experto OTN" en el año 2003, Oracle ACE año 2004 y actualmente Oracle ACE Director.

Mahir es un DBA senior con más de 10 años de experiencia en la base de datos Oracle con un enfoque especial en la alta disponibilidad y soluciones de recuperación de desastres (RAC, Data Guard, RMAN ...). Mahir está trabajando en el Banco Central de la República de Azerbaiyán. Él es DBA OCP. Mahir es representante de Azerbaiyán Oracle User Group (AZEROUG); También blogger.

Bruno es un OCE DBA con más de 4 años de experiencia especializada en bases de datos Oracle (9i, 10g, 11g) con enfoque especial en la alta disponibilidad, soluciones de recuperación de desastres (Dataguard, RAC, Recovery Manager), desarrollo (PL / SQL) – realizando actualizaciones, parches, migraciones en diferentes plataformas - Oracle Certified Associate 11g / 11g Oracle Certified Professional / Oracle Certified Expert Rac and Grid Infrastructure 11g.