Oracle Database 12c: “Cloning Plugabble Databases (PDBs)” ( Parte I )

Por Joel Pérez y Wissem El Khlifi
Publicado en Febrero 2014

Indice

1. Oracle Database 12c: “Cloning Plugabble Databases (PDBs)” ( Parte I )
2. Oracle Database 12c: “Cloning Plugabble Databases (PDBs)” ( Parte II )
3. Oracle Database 12c: “Cloning Plugabble Databases (PDBs)” ( Parte III )

Reciban estimados tecnólogos Oracle un cordial saludo. A través del presente artículo, tendremos la oportunidad de visualizar y adentrarnos un poco en el tema de la nueva arquitectura de “Oracle Database 12c” denominada “Oracle Multitenant”, tendremos también la oportunidad de explorar el tema de “Cloning” de “PDBs” enfocado en uno de sus tantos escenarios.

“Database12c” la nueva versión de manejador de base de datos de “Oracle Corporation”, nosotros los tecnólogos Oracle nos preguntábamos “que mas…” podría Oracle adicionar como nuevas características?, de que forma Oracle nos iba a sorprender esta vez y como siempre, las nuevas características y nueva arquitectura no solo nos sorprenden sino que una vez mas nos llevan a otra era…, “Cloud Computing”…

Personalmente he tenido la oportunidad de trabajar con tecnología Oracle como DBA desde su versión 8. “8”i la era del internet, “9i” la era del internet con mayores elementos, recuerdo que uno de los componentes de mayor importancia fue la presentación de RAC9i “la era naciente de RAC…”, “10g” nos sorprendió con el concepto de ASM… y filosofía “Grid Computing”, 11g & 11g R2 sobre todo por sus mejoras de alto nivel relacionadas con RAC & Data Guard…, 12c… Cloud Computing, nuevas características… mas de 500 las cuales iremos cubriendo gradualmente a través de artículos y otros elementos de ayuda.

En la nueva versión de manejador de base de datos “Oracle Database 12c” han sido incorporado mas de 500 nuevas características sin embargo e icono principal de la versión radica en la nueva arquitectura es denominada “Oracle Multitenant”.

“Oracle Multitenant” es la nueva opción para “Oracle Database 12c Enterprise Edition” la cual ayuda a los clientes a reducir costos en el área de “IT” a través de la simplificación, consolidación, aprovisionamiento, “Upgrades” y mas. La nueva arquitectura esta basada en una base de datos “Container” la cual puede albergar muchas BBDDs ( Bases de Datos ) denominadas “Plugaggable Databases”. La arquitectura “Oracle Multitenant” es escalable y aplicable de forma total a soluciones ya conocidas como “RAC ( Oracle Real Application Clusters )” & “Oracle Data Guard”. Una simple BBDD no “Pluggable Database” o bien llamada “Non-CDB” ( “Non Container Database” ) puede ser convertida fácilmente a una BBDD “Pluggable Database” sin afectar su contenido, operación y manejo para las aplicaciones relacionadas con la misma.

Los principales beneficios de la arquitectura “Oracle Multitenant” pudieran ser resumidos en 4 grandes factores:

Alta Densidad de Consolidación: las muchas “Pluggable Databases” poseerán como base de operación la misma BBDD “Container” ( “CBD”: “Container Database” ) compartiendo memoria y procesos “Background”, esto conlleva una gran ventaja, cada BBDD no poseerá su propia “SGA”, existirá solo una “SGA” para todas las BBDDs. En esta nueva arquitectura existirá la posibilidad de operar más BBDDs en un mismo servidor o servidores respecto a las versiones anteriores. Este es un beneficio similar a la llamada concepción de consolidación de “schemas”, pero son bien conocidas las barreras, dificultades e implicaciones al aplicar consolidación de “schemas” lo cual trae consigo un tema de seguridad a resolver para lo cual se tendría que implementar un modelo de protección con “Oracle Database Vault” u otros lo cual si podría afectar en cierta medida la arquitectura de permisos de usuarios y objetos.

Rápido Aprovisionamiento & “Cloning” utilizando SQL “Statements”: una “Pluggable Database” puede ser desconectada de un “Database Containter (CBD)” y ser conectada a otro “Database Containter (CBD)”. Alternativamente se puede clonar una “Pluggable Database” en el mismo “Container” o duplicar la misma de un “Container” a otro “Container”, estas operaciones pueden ser llevadas a cabo a través de “SQL Statements” en tan solo unos pocos segundos.

Nuevos Paradigmas para un Rápido “Patching” o “Upgrade”: la inversión de tiempo y esfuerzo para aplicar un “Patch” a una “Database Containter (CBD)” conlleva el resultado de aplicar el mismo a todas las “Pluggable Databases”, si se desea aplicar el “Patch” o “Upgrade” a solo un numero limitado de “Pluggable Databases” el procedimiento es crear otro “Database Containter (CBD)”, desconectar las “Pluggable Databases” del anterior “Container”, incorporar las mismas al nuevo “Container” y allí realizar el trabajo particular de “Patch” y/o “Upgrade” en este nuevo “Container”.

Manejar muchas BBDDs como una sola: consolidando BBDDs existentes como “Pluggable Databases”, los administradores podrán manejar muchas “Pluggable Databases” como si fueran una sola. Por ejemplo, labores de respaldo y recuperaciones son llevadas a cabo desde del “CBD”, toda la administración podrá ser llevada a cabo de forma centralizada.

“Resource Management” Dinámico entre “Pluggable Databases”: “Oracle Database 12c Resource Manager” posee funciones extendidas para controlar el consumo de recursos entre “CDBs” y “Pluggable Databases”.

Retos de los Clientes direccionados por “Oracle Multitenant”

Es común en tiempos actuales encontrar en las empresas BBDDs distribuidas a lo largo de diversos o muchos servidores. Los costos asociados a manutención, Licencias, repetición de labores a lo largo de estas hacen que el área de “IT” estuviese en constante búsqueda de optimizar labores evitando realizar una misma tarea muchas veces o que por ende existiese el deseo de reducir costos reduciendo cantidad de servidores entre otras estrategias. “Oracle Multitenant” es la respuesta a la reducción de costos que las compañías deseaban. Esto podría verse reflejado en las siguientes aéreas:

• Memoria: reducción de memoria global requerida por cada instancia de BBDD al consolidar la SGA de todas las instancias en una sola y poseer solo un conjunto de “Background Processes” en lugar de el conjunto de los mismos por cada instancia.
• Aprovisionamiento de BBDDs: para duplicar/clonar una BBDD por lo general se utilizan técnicas que requieren gran cantidad de tiempo, tales como: “RMAN Duplicate”, “Restore/Recover”, “Cold Backups”, “Export/Import”, estas requieren primeramente la creación de los archivos principales de una BBDD los cuales suelen ser realizados a través del “DBCA ( Database Upgrade Assistant )” o de forma manual. “Oracle Multitenant” posee la capacidad de crear y/o duplicar una BBDD con solo un comando.
• “Patching”: de forma regular las tareas de “patching” deben de ser ejecutadas en cada BBDD lo cual dificulta el proceso cuando se posee una gran cantidad. “Oracle Multitenant” posee una arquitectura interna en la cual la “Metadata” de todas las “Pluggable Databases” se encuentra en la “CDB”. La “CDB” es el área donde se encuentra el diccionario de datos y estructura base de las BBDDs, entonces, es propiamente allí el área clave para hacer cambios de diccionario de datos ( en caso de “Upgrades” ) o binarios de Oracle afectados por “Patchings”, de esta manera al realizar el “Patching” del “CBD” a su vez el efecto se vera reflejado en la operación de todas las “Pluggable Databases” conectadas con un respectivo “Container”.
• “Upgrade”: la tarea de “Upgrade”/Migración de una BBDD consiste en actualizar el catalogo/diccionario de la misma y por consiguiente el compilado de los objetos de usuarios ( procedimientos, vistas, funciones, y otros.. ) de la BBDD que pudiesen haberse afectados en su validez a causa de invalidez temporales de otros objetos dependientes ( Catalogo de la BBDD ), para el caso de “Upgrades”, los objetos dependientes son aquellos pertenecientes al catalogo de la BBDD. Hasta versiones previas a “Oracle Database 12c” el realizar el “upgrade”/”downgrade” de una BBDD requería una ardua labor de muchas etapas, duplicar la BBDD original para realizar: “Manual Rolling Upgrade”, uso del “DBUA ( Database upgrade Assistant )”, etc y muchas técnicas mas. Una de las tantas inquietudes de muchos clientes siempre ha radicado en si existe un método para realizar “Downgrades” rápidos en caso de posibles problemas con la nueva versión implementada o como poder deshacer un “Patch” de la manera mas rápida posible en caso de problemas con el mismo sin tener que realizar operaciones riesgosas o sin tener que asegurar el estado anterior de los binarios a través de un “Backup” de los binarios del manejador. Todo el proceso de reversión radica en los cambios realizados en el “core” de la BBDD: ( Catalogo de la BBDD & Binarios ), si ahora el “core” de la BBDD es la “CDB” y existe la posibilidad de poseer varias versiones de “Containers” entonces es aquí la arquitectura ( “Oracle Multitenant” ) que hace posible que nuestro “core” sea tan dinámico y flexible para las BBDDs. Solo basta con desconectar una BBDD de un “Container” para conectarla a otro y así poder acceder a una “Pluggable Database” en versiones y/o “Patchs” diversos casi de manera inmediata.
• “Backups & Recover”: la gestión de respaldos y recuperaciones hasta versiones anteriores a “Oracle Database 12c” se tenia obligatoriamente que realizar de forma local en cada BBDD, con Oracle “Multitenant’ la gestión es desde la “CDB” correspondiente.

Algunas Características Particulares de Oracle “Multitenant”

• En arquitectura “Multitenant” el diccionario de datos es virtualizado
• En “Oracle 12.1’ puede haber un máximo de 252 BBDD por “Container”
• Posterior a un “Upgrade” las nuevas BBDDs 12c pueden ser “Pluggable Databases” o “Non-Pluggable Databases”
• Reconocimiento total entre BBDDs “Pluggable Databases” y no “Non-Pluggable Databases”, el funcionamiento para las aplicaciones es exactamente igual para “Pluggable Databases” y no “Non-Pluggable Databases”
• La conexión y desconexión ( “Plug/Unplug” ) de “PDBs” de o a los “Containers” representanta internamente una combinación de “Transportable “Tablespaces” en conjunto con una 3ra generación de “Data Pump”
• El “Unplug/Plug” se podrá realizar entre sistemas operativos de diferentes “endian formats”. Las capacidades de “Oracle Database 12c” de operar BBDDs entre sistemas operativos mixtos escala a técnicas como: Transporte de Tablespaces, “Restore/Recover” y mas
• Las conexiones “Oracle NET” hacia las “PDB” siguen siendo iguales
• “SQL Developer” & “Enterprise Manager” han sido extendidos para exponer y manejar todo lo relacionado con la arquitectura “Multitenant”
• Las operaciones de “Oracle Active Data Guard” son conducidas a nivel de la “CDB”
• La desconexión y conexión a “CDBs” puede ser llevado a cabo entre “CDBs” de diversas versiones
• La nueva arquitectura “Multitenant” esta disponible en versiones “Standard”, “Standard Edition One” & “Enterprise Edition”. Sin la licencia de opción “Multitenant” se tendrá derecho a solo una “PDB”

Organizacion Interna de Objetos y “Tablespaces” en Arquitecturas No “Multitenant” & “Multitenant”

• La figura desplegada a continuación es la representación de la localización y organización de la “Metadata” típica de una BBDD “Non-CDB”. La “Metadata” se encuentra en el “Tablespace” “System” y sus objetos pertenecen al diccionario de datos de la BBDD. La creación de cualquier objeto en la BBDD enfila registros y/o modificaciones a la información interna de estas. En el diccionario de datos se encuentra toda la información relacionada con usuarios (user$), “Tablespaces” (TS$) y mas.

• La información del diccionario de datos e información de data de aplicación por mejoras practicas siempre se distribuye en “Tablespaces” diversos:

• El modelo de la siguiente figura es la arquitectura de “Tablespaces” y objetos de una “CDB”. En la parte superior de color rojizo nos encontramos el contenido del “Container” de BBDD en uso. Debajo la representación de la “Oracle System Metadata” ya propiamente relacionada con una “PDB”. La información de la parte inferior esta basada en la información del diccionario de datos para el “Oracle System Metadata” y la parte superior para el registro de los objetos de aplicaciones.

Algunos “Tips” de Administración de “Pluggable Databases”

• “Unplug/plug” Desconexión & Conexión de una “PDB” de una maquina a otra: en la siguiente representación se muestra la “PDB” llamada “PDB_1” conformada a una “CBD” denominada “CDB_1” en la maquina 1. Se desea movilizar la “PDB” ( “PDB_1 ) a la maquina 2. Mientras la “PDB_1” esta conectada a la “CDB_1” es la BBDD “CDB_1” quien posee toda la información de la ubicación de “Datafiles” y otros elementos de la “PDB_1” , información que se encuentra alojada en los “Controlfiles” de la “CDB_1”. Para llevar a cabo la desconexión “unplug” la información contenida en la “CBD_1” perteneciente a la “PDB_1” debe ser exportada a un archivo que será pieza clave en el proceso de conexión “Plug” de la “PDB_1” a la “CDB_2” en la maquina 2. La generación del archivo mencionado será de la siguiente forma:

-- The PDB must be closed before unplugging it. 
alter pluggable database PDB_1
unplug into '/u01/app/oracle/oradata/.../pdb_1.xml';

Para realizar el “plug” de la “PDB_1” en la maquina 2, ejecutaremos la siguiente porción de código:

-- The PDB must be opened after plugging it in. 
create pluggable database PDB_2
using '/u01/app/oracle/oradata/.../pdb_1.xml' path_prefix = '/u01/app/oracle/oradata/pdb_2_Dir'

    

El traslado de “PDBs” es un aérea completa de estudio, lo anteriormente expuesto es solo una de las tantas técnicas posibles a realizar, el tema completo de Movilización de “PDB” lo abordaremos en artículos sucesivos.

• “Cloning PDB”: para duplicar una “PDB” existen diversas vías y modos. Si se decide utilizar los métodos tradicionales de copia de “Datafiles” a nivel de sistema operativo, etc entonces se tendrá que proceder a realizar el “unplug” de la BBDD y aplicar los pasos correspondientes. Otra vía estaría basada en el escenario de cuando una “PDB” esta en uso, allí los “foreground processes” copian los archivos a la nueva locación y realiza el “plug” de la misma. Para la versión 12.1.0.1 la “PDB” origen debe estar en modo “Read Only” para llevar a cabo la operación de “Cloning”, si se intentara con la mencionada versión en modo “open”, se obtendría el siguiente mensaje de error:
  
  

  Error: (The attempt causes ORA-65081: database or pluggable database is not open in read only mode.)
  
  Para versiones posteriores a la “12.1.0.1” se podrá llevar a cabo “Cloning” de “PDB” in “Flight” sin establecer la BBDD original en modo “Read-Only”.

• “Cloning PDBs” usando “snapshot copy”: desde ciertos tiempos a la fecha diversos “vendors” de “filesystems” tales como “Oracle Corporation” con su solución “Sun ZFS”, NetApp y otros han expuesto en el mercado métodos para copiar archivos de gran tamaño  a través de un método que representa poco tiempo de ejecución, dándose estos por el orden de los segundos. Realmente la copia no es una copia física tradicional basado en copias de bloques, el método se basa en que el archivo destino establece apuntadores a los bloques del archivo original y en la medida de que el archivo original va modificando sus bloques originales, las versiones originales de estos bloques son transferidos al archivo destino, este método computacional es denominado en el mercado por la mayoría de empresas como “copy-on-write”, este método es el internamente utilizado por la clausula “snapshot copy” para el “Cloning” de BBDD.
  
  En la arquitectura “Multitenant” los “foreground processes” envían una solicitud al sistema de almacenamiento para copiar  los “Datafiles” de la “PDB” utilizando un protocolo de seguridad dedicado.
  
  “Snapshot PDB Cloning” es soportado solo cuando la nueva “PDB” es creada en el mismo “Container” del cual pertenece la “PDB” origen a clonar.
  
  La “PDB” creada utilizando “Snapshot copy” no puede ser “unplugged” debido a que gran parte de sus bloques de uso, obtienen la verdadera información con punteros a archivos de la BBDD original por lo tanto no posee autonomía al 100% de la información contenida en sus “Datafiles”. Ambas bases de datos ( origen y copia ) pueden obtener apertura en modo en modo “Read-Write”.
  
  En “12.1.0.1” los siguientes “filesystems” soportan “snapshot PDB Cloning”: “Sun ZFS”, “NetApp” & “Oracle ACFS”. El siguiente error es reportado si se intenta crear una “snapshot PDB Cloning” en otro tipo de filesystem.
  
  Error: (The error is ORA-17517: Database cloning using storage snapshot failed.)

A este punto del artículo tenemos la base de conocimiento necesaria para entender la filosofía de las “PDBs” e iniciar el camino de conocimiento de administración de las mismas. En el presente articulo mostraremos una de las tantas formas bajo las cuales podremos clonar “PDBs”.

Objetivo y escenario: Generar una copia de “PDB” en el mismo “Container” base de la “PDB” original utilizando OMF.

Herramienta de Uso: SQL*Plus

Los motivos bajos los cuales podríamos desear generar copias de “PDBs” son extensos y diversos, listemos algunos:

• Deseo de realizar un “test” de un “Patch” de aplicación de nuestra “PDB” de producción. En este caso primero se realiza el “Clone” de la BBDD de producción, se aplica el “Application Patch” a la copia y se procede al “test” del mismo.
• Deseo de realizar diagnósticos de posibles regresiones de rendimiento de las aplicaciones
• Deseo de análisis de impacto de posibles cambios a realizar en producción
• Esto y mas..., la concepción de duplicar BBDDs para realizar diversos tipos de “test” es algo que ha pertenecido siempre al ciclo de vida de las BBDDs de Producción, Calidad, “Tests”, “Oracle Multitenant” a través de su arquitectura facilita un “Provisioning” con mayor facilidad y flexibilidad.

Para el siguiente ejemplo se asume que se posee una combinación de “CBD” & “PDB” creadas las cuales denominaremos: “CDB1” & “PDB1”, el objetivo será generar una “PDB2” sobre el mismo “Container” “CDB1”. Tal como fue resaltado, para el caso presente el objetivo es probar cambios internos en la BBDD concernientes a  una determinada aplicación, si los cambios a la nueva “PDB” fuesen direccionados para hacer “test” de “Upgrades” o “Patchs” lo adecuado seria crear otro “CDB” y realizar el “Plug” de la nueva “PDB” en este nuevo “Container”. Pasemos a visualizar el ejemplo practico.

Establecimiento en modo “Read-Only” de la “PDB1”

Recordemos que para la versión “Oracle Database 12cR1” el “Cloning” en este escenario exige el establecimiento en modo “Read-Only” de la “PDB” original ( “PDB1” ). Conectados a la “CBD1” aplicamos:

. oraenv
ORACLE_SID = [CDB1] ? CDB1
sqlplus / as sysdba
alter pluggable database pdb1 close immediate;

Apertura de la “PDB1” en modo “Read Only”

alter pluggable database pdb1 open read only;
exit

Creación de nuevo Directorio para la “PDB2”

mkdir /u01/MyNewPDB2
chown oracle:oinstall /u01/MyNewPDB2
chmod 775 /u01/MyNewPDB2

Configuracion de “OMF” ( “Oracle Managed Files” ) para la “PDB2”

sqlplus / as sysdba
alter system set db_create_file_dest='/u01/MyNewPDB2';

Ejecución del “Cloning”

create pluggable database pdb2 from pdb1;

“Opening” de la nueva “PBD2”

 alter pluggable database pdb2 open;
 

Reestablecimiento de Condiciones para la “PDB1”

Cerrado de la “PDB1” para su apertura posterior en modo “Read-Write”

connect / as sysdba
alter session set container=cdb$root;
alter pluggable database pdb1 close immediate;
alter pluggable database pdb1 open;

Así es de fácil realizar un “Clone” de una “PDB”… esto es “Oracle Multitenant”!!

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.

Wissem es un Senior DBA con más de 12 años de experiencia, especializado en soluciones RAC & Data Guard. Actualmente labora para “Schneider Electric / APC Global operations”. Wissem ha trabajado también para varias empresas internacionales líderes en sectores de Bancas, Telecomunicaciones, Internet y Energía. Wissem fue el primer Oracle ACE en España y es un OCP DBA