Definitivamente cada vez que hablemos de Oracle Database 12c, será de materia obligatoria, conversar sobre la nueva características del Contenedor Multitenant.
Multitenant es igual a decir "Virtualización a nivel de Base de Datos", sin tener que acudir, a la prehistórica opción de virtualización de hardware, con todos sus inconvenientes. Ciertamente, la virtualización fue una excelente opción de como aprovechar de la mejor manera posible, los pocos recursos de hardware a los cuáles teníamos acceso, consolidando plataformas y simplificando la labor de administración. Pero que sucedía, si la cantidad de recursos asignados a una máquina virtual, no eran los suficientes para atender las necesidades de los sistemas alojados?. Ni modo, había que bajar la máquina virtual, redimensionar los recursos físicos asignados, hacer los ajustes respectivos a nivel de estructuras de memoria, cpu, almacenamiento, etc, levantar los servicios y monitorear durante un tiempo los cambios realizados, para determinar la efectividad de los mismos, con la consecuente pérdida de disponibilidad de los servicios huésped de nuestro servidor.
Si teníamos suerte, la mayor parte de los problemas podrían resolverte, sacando nuestra barita de "Harry Potter". Tal vez antes de determinar los cambios, utilizabamos nuestra experiencia y conocimiento, para acercarnos a los montos de ajuste requeridos, pero era una ruleta rusa.
Este esquema de ajuste, carente de dinamismo y efectividad técnica, es prácticamente hoy en día poco aceptable para la mayoría de las empresas, que trabajan bajo un sistema de alta disponibilidad
La característica de Multitenant en el nuevo Oracle Database 12c, es la pieza de arquitectura más importante, que el equipo de ingeniería de bases de datos, ha agregado en los últimos 10 años.
Multitenant es sinónimo, de muchas bases de datos corriendo en una pieza de hardware, sobre la cuál, el motor de la base de datos posee control absoluto, logrando de esta manera, asignar o ajustar los recursos disponibles, aplicando políticas de niveles de SLA's. Es fundamental, para que este concepto sea un éxito, que podamos garantizar, que cada ambiente que se ejecuta en la pieza de hardware, no se va a ver afectado, por la actividad de los otros ambientes residentes dentro del "Contenedor".
CPU, memoria, procesador, I/O, en fin todos los recursos de hardware, serán controlados por el "Contanier" que tiene la capacidad, para dimensionar en "Caliente", sin necesidad de reiniciar una base de datos, todos estos recursos, según el cliente lo halla solicitado.
Cada "Contenedor" tiene la capacidad, de mantener aislada la información de cada instancia de base de datos, llamada ahora PDB ( Pluggable Database ), dentro de un sólo conjunto de estructuras de memoria, que son compartidas por todos los PDB's establecidos.
Aquí es donde encuentra razón y sustento, la tecnología de "Multitenant". Cuando tenemos instancias de bases de datos en las versiones previas a #DB12c, cada instancia maneja su propio grupo de estructuras de memoria ( SGA ), procesos background y estructuras físicas ( datafiles, controlfiles, redologs, spfiles, etc ).
Las áreas de memoria definidas para el SGA, son bloqueadas, no permitiendo que otros procesos que se ejecutan en el servidor, tengan acceso a estos recursos. Si sobredimensionamos el tamaño del SGA o peor aún, lo subdimensionamos, estaremos en un primer caso, desperdiciando recursos de hardware y en el segundo, obteniendo problemas de rendimiento ( performance ).
En "Multitenant", todos los PDB´s que en el caso de esta primera versión en #DB12c, puede alojar hasta 252 instancias de bases de datos PDB, los recursos son compartidos por todas las instancias, evitando así el desperdicio. Yo puedo reservar cierto grupo de recursos y tenernos disponibles, para utilizar como un "Pool" y asignar de manera "Dinámica" a un PDB "X", en caso que los niveles de SLA's, se estén poniendo en peligro.
El mantenimiento es otro punto alto en esta tecnología, ya que todas las bases de datos se administran como si fueran una sola. Yo puedo crear usuarios DBA's a nivel de "Contenedor" y hacerlos globales para todas las instancias, como por ejemplo, para realizar tareas de respaldo de información o mantenimiento. Un sólo respaldo puede hacerse a nivel de "Contanier" y de manera granular, realizar recuperaciones a nivel de cada PDB.
Desde cualquier punto de vista que lo vea, si ahora puedo tener control sobre los recursos de hardware desde el propio motor de la base de datos y administrarlos de forma dinámica, para que quiere hacer una virtualización prehistórica a nivel de hardware?
Esta tecnología crea un nuevo paradigma y un universo de oportunidades, para las empresas y para sus usuarios. Tendremos oportunidad de hablar sobre aspectos específicos del funcionamiento de "Oracle Database 12c Multitenant", característica que esta únicamente disponible en la edición corporativa ( Enterprise Edition ) y que tiene un costo adicional, como cualquier otro opcional clásico, como RAC, ADG, Particionamiento ó Security.
Asignación de ID para elementos del Contenedor:
- Total CDB = Container ID = 0
- Root (CDB$ROOT) = Contenedor ID = 1
- Seed (PDB$SEED) = Contenedor ID = 2
- PDBs = Contenedor IDs = 3 al 254
Obteniendo el ID dentro de un PDB o en el CDB (En el PDB1):
SQL> SHO CON_ID CON_NAME
CON_ID CON_NAME
------------------------------ ------------------------------
3 PDB1
(Connectado a ROOT):
SQL> connect / as sysdba
SQL> SHO CON_ID CON_NAME
CON_ID CON_NAME
------------------------------ ------------------------------
1 CDB$ROOT
