Oracle 12c : Nueva Arquitectura Multitenat Database

Ha pasado casi 1 años desde que la nueva versión de la base de datos Oracle 12c vio la luz. 
Junto con Oracle 12c llegaron nuevos conceptos y funcionalidades. 

Tal vez el cambio más importante ha sido el desarrollo de una nueva arquitectura llamada Multitenant Database.

Es por eso que quiero dedicar mi primer post a explicar un poco de que se trata esta nueva arquitectura. 

Arquitectura Pre-12c

En versión anteriores de base de datos solo existía un tipo de arquitectura donde se tenía una Instancia, los procesos background y una estructura física llamada base de datos.

En los últimos años, muchas empresas empezaron a consolidar gran numero de bases de datos en servidores con infraestructuras bastante robustas.  Teniendo el siguiente escenario

Cada Instancia ocupa un espacio de memoria propio, cada base de datos posee su propio conjunto de procesos background, su propio grupo de server process y su propio diccionario de datos.

Cada base de datos necesita una administración independiente por parte de los DBAs.

En Oracle12c a esta arquitectura se le conoce con el nombre de Arquitectura NON-CDB.

Arquitectura 12c

Oracle 12c introduce una nueva arquitectura llamada Oracle MULTITENANT en la que se provee, a la base de datos, la capacidad de convertirse en un gran contenedor de bases de datos.

El contenedor es definido con el nombre de Multitenant Container Database (CDB)  donde pueden ser incluidas desde 0 a mas bases de datos llamadas Pluggable Databases (PDB). 

En el siguiente grafico se detalla cómo está compuesto el Multitenant Container Database (CDB)

Como se puede observar el CDB está formado por una Instancia (SGA + PGA), un grupo de procesos background, un contenedor Root y muchas bases de datos Pluggable (PDB). 

Al tener una sola Instancia, todos los PDBs comparten las mismas estructuras de memoria y, en consecuencia, el mismo archivo de parámetros spfile o pfile.

Si un cliente quiere consolidar muchas bases de datos en un solo servidor puede hacer uso de esta arquitectura y tener una sola instancia con muchas bases de datos de tipo Pluggable database.   
Esto ayuda a optimizar el uso de la memoria debido a que se utiliza una gran instancia y un solo grupo de procesos background para todas las bases de datos Pluggable (PDB)

Describiremos con más detalle los contenedores que forman parte del CDB

1. Contenedor ROOT

Cuando se crea una base de datos CDB, automáticamente se crea un contenedor ROOT.

El contenedor ROOT, conocido también como CDB$ROOT, es utilizado para almacenar la metadata que soporta la arquitectura CDB.  Además, almacena las estructuras globales de una base de datos.  

Dentro del contenedor ROOT podemos encontrar:

a) Control Files: Se define como una estructura global en el CDB por lo que existe solo un grupo de controlfiles que soportan al CDB y todos los PDBs definidos.

b) Redolog Files: Como los redologs se relacionan directamente con el Redolog Buffer se define también como una estructura global dentro del CDB, es decir, se tiene un solo grupo de redologs que soportan la actividad del CDB y los PDBs.

c) Undo Tablespace: Como sabemos las transacciones son manejadas a nivel de Instancia.  El Undo tablespace está relacionado directamente con las transacciones (posee la información necesaria para que una transacción puede hacer rollback).  
Al tener una sola instancia es necesario tener un solo UNDO tablespace que soporte la transaccionalidad del CDB y todos los PDBs.

d) Temp Tablespace: El tablespace Temporal dentro del Contenedor ROOT es obligatorio. Soporta la actividad temporal de todos los PDBs, incluyendo el contenedor Root.

Como se puede observar en el grafico cada PDB puede tener su propio tablespace temporal. Sin embargo, si un PDB no tiene definido su propio tablespace temporal, utilizará el tablespace Temporal del contenedor ROOT.

e) System y Sysaux Tablespace: Como indicamos anteriormente, el contenedor Root almacena toda la metadata necesaria para soportar la arquitectura CDB.  Toda la metada es almacena en los tablespaces System y Sysaux del contenedor Root.

Es interesante observar como la nueva arquitectura separa los objetos propios de Oracle (paquetes como DBMS_OUTPUT, DBMS_STATS, DBMS_SCHEDULER, etc) de la metadata propia de las bases de datos Pluggable.

Gracias a esta separación, la base de datos Pluggable es independiente del Contenedor. De esa manera, una base de datos Pluggable puede ser desconectada (Unplug) de un contenedor y conectada (PlugIn) en otro de manera sencilla y rápida.

Debido a esta característica es que se le denomina base de datos Pluggable.  Por la acción en ingles de PlugIn  y Un-Plug la base de datos de un contenedor a otro.

2. PBD SEED

Es una base de datos Pluggable que se crea junto con la creación del CDB.  Su función principal es la de ayudar a crear nuevas bases de datos Pluggable de manera rápida y sencilla.

Es importante señalar que esta base de datos siempre está en estado READ ONLY.

3. PBD DATABASES

Bases de datos que almacenan la información de las aplicaciones.  Se componen de usuarios, esquemas y objetos propios de la aplicación que interactúa con la base de datos.

Posee su propio conjunto de tablespaces que no son compartidos por otro PDB o por el contenedor ROOT.

Una características principal de los PDBs es que son bases de datos independientes y aisladas.  Los objetos en un PDB no pueden ser visualizados por otro PDB.  Existen reglas de seguridad que aseguran el aislamiento total de cada PDB dentro de un CDB,

Las aplicaciones siguen pensando que las bases de datos con las que interactúan son independientes una de otra.

Como se comento anteriormente, una base de datos PDB puede tener o no un tablespace Temporal.  Si no tuviese uno, el espacio temporal que necesita lo utiliza del tablespace Temporal del contenedor ROOT.

Los tablespace SYSTEM y SYSAUX solo almacenan la metadata propia del PDB para poder facilitar el conectado y desconectado del PDB de un Contenedor.

Ventajas de la nueva Arquitectura

-          Evita redundancia de información en el diccionario de datos.

-          Seguridad: Separación de información entre cada pluggable database. Un usuarios que se conecta a un PDB no puede ver la información de otro PDB.

-          Aprovisionamiento o Clonado de una base de datos se realiza de manera más sencilla.

-          Se puede tener una administración independiente (DBA) por cada PDB.

-          Después de un upgrade a Oracle 12c una base de datos puede ser conectada a un CDB.

-          Manejo de recursos por cada PDB mediante Resource Manager.

-          Administración de backups Centralizado.

-          Los upgrade se realizan a nivel del Contenedor (CDB), de esa manera, solo es necesario un upgrade para todas las bases de datos Pluggable.

NOTA

Es importante indicar que la arquitectura Multitenant puede requerir de una licencia dependiendo de cómo se haya definido la arquitectura. 

Configuración Singletenant: Cuando se tiene un contenedor con una base de datos Pluggable.  Esta arquitectura no requiere de licencia.

Configuración Multitenat: Cuando se tiene un contenedor con más de una base de datos Pluggable.  Esta arquitectura requiere de una licencia extra llamada Oracle Multitenant

En este articulo solo he hecho una introducción a la nueva arquitectura Multitenant.  En posteriores post se mostrará cómo se administra esta nueva arquitectura, además de nuevas funcionalidades de la versión Oracle 12c.

Espero les pueda servir de ayuda.