Oracle 12c : Administración de bases de datos CDBs y PDBs

Cuando inicie la revisión de la nueva arquitectura Oracle 12c me fui dando cuenta que con una nueva arquitectura se tiene una nueva forma de administración.

Empecé a tener muchas preguntas relacionadas a la administración de la arquitectura Oracle 12c:

¿Cómo conectarme a un CDB y PDBs?

¿Cómo saber a qué contenedor estoy conectado?

¿Cuál es el proceso de inicio y apagado de un CDB y PDBs?

¿Qué vistas puedo revisar para observar la configuración de un CDB y PDBs?

¿Cómo se administran los tablespaces?

¿Cómo se definen los default tablespaces en esta nueva arquitectura?

¿Se puede modificar parámetros de base de datos en un PDB?

En este articulo responderemos a esas dudas que normalmente tenemos al iniciar con esta arquitectura.

¿Cómo conectarme a un CDB y PDBs?

El CDB es administrado desde el contendor ROOT y para poder conectarse se puede utilizar dos formas:

Conexión Local

Conexión a través del LISTENER

Para poder conectarnos a los PDBs utilizamos el LISTENER. 

 

Pueden darse cuenta que cada vez que se crea una nueva base de datos PDB, el LISTENER lo registra como un nuevo servicio.

Otra forma de conectarse a los contenedores es mediante el parámetro de sesión CONTAINER

Para poder utilizar este método es necesario estar conectado con un usuario COMUN para todos los contenedores (los usuarios comunes los explicaremos en posteriores articulos)

¿Cómo saber a qué contenedor estoy conectado?

Como administradores, muchas veces vamos a tener la necesidad de movernos del contendor ROOT a los diferentes PDBs o viceversa.

Para evitar realizar tareas sobre un contendor equivocado siempre es bueno consultar en que contenedor (ROOT o PDB) estamos actualmente.  Podemos hacerlo con el comando SHOW CON_NAME

Tambien podemos consultar el código del contendor con el comando SHOW CON_ID

¿Cuál es el proceso de inicio de un CDB y PDBs?

El proceso de inicio de la base de datos es el siguiente

Para subir la base de datos a estado NOMOUNT

Para subir la base de datos a estado MOUNT

Para subir la base de datos en estado OPEN

Verificamos si el contenedor ROOT y el PDB SEED ya se encuentran abiertos.

Finalmente procedemos a abrir cada PDB de forma individual

O todos al mismo tiempo

Observando el proceso de inicio de un CDB y los PDBs se crea una nueva duda.

¿ Cada vez que levantamos el CDB tenemos que lanzar un comando mas para levantar los PDBs?

Para ahorrar tiempos de inicio de bases de datos;  Oracle ha creado un nuevo tipo de TRIGGER AFTER STARTUP.

Con este nuevo TRIGGER podemos crear una rutina que inicie todas los PBDs cuando la base de datos inicia.

¿Cuál es el proceso de apagado de un CDB y PDBs?

El proceso de apagado de la base de datos es el siguiente:

Podemos cerrar cada PDB de forma individual

O podemos cerrar todos los PDBs al mismo tiempo.

Otra forma de cerrar un PDB es conectarse al PDB y lanzar el comando SHUTDOWN IMMEDIATE

Si nos conectamos al contenedor ROOT y ejecutamos SHUTDOWN IMMEDIATE, todos los PDBs se cerraran automáticamente y posteriormente lo hará el CDB.

Si nos conectamos al contenedor ROOT y ejecutamos SHUTDOWN TRANSACTIONAL, la base de datos espera a que finalicen solo las transacciones del contendor ROOT. Los PDBs se cierran de forma IMMEDIATE

¿Qué vistas puedo consultar para observar la configuración de un CDB y PDBs?

Con la nueva arquitectura se han desarrollado nuevas Vistas de diccionario que nos permiten revisar el estado de los contendores, así como también, el estado de los elementos dentro de cada contenedor.

También encontramos modificaciones a vistas ya conocidas para poder soportar la nueva arquitectura.

Entre las vistas principales tenemos

V$DATABASE

Se le ha aumentado nuevos campos para poder diferenciar entre una base de datos CDB y Non-CDB

V$PDBS

Tal vez la vista que más se utiliza en esta arquitectura.  Esta vista muestra las características y el estado de los PDBs dentro de un CDB.

Es importante anotar la particularidad en el nombre de la vista.  Es una vista V$, sin embargo, se define en plural.

Es importante tomar atención al campo CON_ID ya que es el código identificador de cada PDB.  Es el campo por el que se relaciona cada elemento con su contendor.
 

 

Pueden darse cuenta que en la vista V$PDBS no muestra al contendor ROOT, es porque el contendor ROOT es considerado como el contendor CDB.

Para poder ver la información del contendor ROOT utilizamos la siguiente vista

V$CONTAINERS

Vista que nos muestra la información de todos los contendores en la base de datos. Es muy parecida a V$PDBS pero también contiene la información del contendor ROOT.

CDB_XXX

Muchos conocemos las vistas del diccionario de datos USER_XXX, ALL_XXX y DBA_XXX.  Cada una con un nivel de acceso diferente a la información.

Para la nueva arquitectura Oracle 12c se ha creado un nuevo nivel de acceso a través de las vistas CDB_XXX

Todas las vistas DBA_XXX que conocemos tienen su vista CDB_XXX.  En el siguiente cuadro muestro el homónimo (a nivel Multitenant) de algunas vistas conocidas.

Vista de Base de datos	Vista del contendor Multitenant
DATABASE_PROPERTIES	CDB_PROPERTIES
DBA_USERS	CDB_USERS
DBA_TABLESPACES	CDB_TABLESPACES
DBA_DATA_FILES	CDB_DATA_FILES
DBA_ROLES	CDB_ROLES
DBA_OBJECTS	CDB_OBJECTS
DBA_TABLES	CDB_TABLES

En todas las vistas CDB_XXX encontraremos los mismos campos que en las vistas DBA_XXX mas el campo CON_ID que indica a que contenedor pertenece el elemento.

Cuando se consulta una vista CDB_XXX en el contenedor ROOT, la vista muestra la información de los elementos en todos los contenedores de la base de datos.

Cuando se consulta la misma vista CDB_XXX, conectado a algún contenedor en particular (por ejemplo un PDB) la vista muestra solo la información de dicho contendor.

CDB_PDBS

Dentro del grupo de vistas CDB_XXX encontramos una nueva vista llamada CDB_PDBs que entregan más información sobre cada PDB en la base de datos.

¿Cómo se administran los tablespaces?

La mayoría de tablespaces son independientes en cada contenedor. Los únicos tablespaces que son compartidos por todos los contendores son el tablespace UNDO y, en algunas ocasiones, el tablespace TEMPORAL.

Solo existe un UNDO tablespace en toda la base de datos y se crea en el contenedor ROOT.

El tablespace TEMPORAL que se crea en el contenedor ROOT puede ser utilizado por los PDBs, siempre y cuando, dicho contendor no tengan un tablespace Temporal definido.

En el ejemplo se puede observar que la base de datos PDB2 no tiene un tablespace temporal, por lo que utiliza el tablespace temporal del contendor ROOT.

Para los tablespaces de datos, cada contendor o PDB maneja sus propios tablespaces.  Se puede tener el mismo nombre de tablespaces en diferentes contendores o PDBs. 

¿Cómo se definen los default tablespaces en esta nueva arquitectura?

Como observamos anteriormente, cada contendor o PDB maneja sus propios tablespaces de datos y, en ocasiones, sus propios tablespaces temporales.

En consecuencia, cada contenedor puede definir sus propios tablespaces por defecto.

¿Se puede modificar parámetros de base de datos en un PDB?

En Oracle 12c se puede apreciar que solo hay una instancia para todos los contendores PDBs.  Con una sola instancia, se tiene solo un archivo de parámetros PFILE o SPFILE. 

Con esta afirmación es común pensar que todos los parámetros se definen por igual para todos los contenedores.

Sin embargo existen algunos parámetros que pueden ser configurados de manera independiente en cada contenedor.  Los parámetros que pueden modificarse pueden ser revisados de la vista V$PARAMETER donde el campo ISPDB_MODIFICABLE tiene el valor de TRUE.

Por ejemplo podemos modificar el parámetro OPTIMIZER_MODE en una de las bases de datos PDB.

Cuando coloco scope=spfile le estoy indicando a la base de datos que active el cambio cuando reinicie el PDB.

En el contendor ROOT podemos ver los valores que se le asigna a un parámetro en los diferentes contendores.

Los valores de estos parámetros no se almacenan en el archivo de parámetros PFILE o SPFLE.  Se almacenan en el diccionario de datos de cada PDB.

Conociendo un poco más de la administración de la nueva arquitectura podemos tener más control sobre las tareas que realizamos en cada contendor.  De esta forma nos volveremos más eficientes y, en poco tiempo, dominaremos las nuevas tareas de administración que tiene Oracle 12c.

Espero les pueda servir de ayuda.