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

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

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.