viernes, 13 de junio de 2014

UN VISTAZO A LA NUEVA VERSIÓN DE BASE DE DATOS ORACLE: 12C

Que tal amigos!


La recien liberada versión Oracle 12c nos ofrece una nueva arquitectura: 'MULTITENANT DATABASE'.

Un ejemplo común en Internet de este tipo de arquitectura es la de un tren. Con la arquitectura tradicional de Oracle tendriamos una locomotora  con un vagon de carga enganchado o 'conectado'. Si vamos a agregar un vagón, tendriamos que conseguir otra locomotora para conectar el nuevo vagón. Al final tendriamos dos locomotoras, cada una arrastrando su propio vagón.

En la arquitectura 'MULTITENANT' tendriamos una sola locomotora arrastrando los dos vagones. La locomotora principal vendria siendo el 'CONTAINER DATABASE' y los vagones serían las 'PLUGGABLES DATABASE'. La memoria 'PGA', 'SGA'  y  los procesos de 'BACKGROUND' como 'PMON' y 'SMON' únicamente va residir en el 'CONTAINER DATABASE'.

Si generamos la base de datos con el asistente 'DBCA' de Oracle con la opción 'MULTITENAT' tendriamos la siguiente arquitectura:

  1. Una base de datos 'CONTAINER DATABASE ' generada automáticamente por Oracle identificada con el nombre CDB$ROOT'
  2. Una base de datos 'PLUGGABLE DATABASE' generada  por Oracle para uso interno del  manejador, conocida como base de datos 'sembrada'  identificada con el nombre 'PDB$SEED'.  Esta se encuentra en modo 'READ ONLY' y es utilizada como un 'template'  por parte del manejador para generar  nuevas bases de datos 'PLUGGABLES'.
  3. Una (o más)  'PLUGGABLE DATABASE' donde van a residir los datos de los aplicativos. Por ejemplo si vamos a tener una base de datos para un aplicativo 'CRM' tendriamos la base 'PDBCRM' y otra 'PDBDWH' para un Datawarehouse.
Del diccionario de datos de Oracle compuesto por las vistas  'DBA_' ,'USER_' , y 'ALL_', habra que familiarizarse un nuevo grupo de vistas identificadas con el prefijo 'CDB_'.  En estas últimas podremos visualizar los objetos residentes tanto en el 'CONTAINER' como en las bases de datos  'PLUGGABLES'.

En versiones anteriores a Oracle 12c,  debiamos realizar una consulta a la tabla 'DBA_TABLES'  de cada instancia de Oracle para conocer el total de tablas. En 12c, con una consulta a la tabla 'CDB_TABLES' podremos conocer las tablas de cada base de datos identificadas con una nueva columna :  'CON_ID' que nos va indicar en que base nos encontramos. Por default, Oracle asigna los siguientes valores a la columna 'CON_ID'

  • Valor de 0 según la documentación de Oracle incluye tanto el 'container' como las base de datos no 'container.
  • Valor de 1  para el container 'CDB$ROOT'
  • Valor de 2 para la base de datos 'sembrada' o 'PDB$SEED'
  • Valor de 3 o más para las bases de datos donde van a residir la información de aplicativos
Si requerimos el nombre de todas las tablas de los diferentes aplicativos, lo realizariamos con un 'SELECT table_name FROM cdb_tables where CON_ID>2',  sin necesidad de utilizar un viejo conocido : el  'export ORACLE_SID=id_instancia'  requerido para cambiarse de instancia.

Cuando ingresamos a una configuración tipo 'MULTITENANT', por default nos va a posicionar en la base de datos contenedor o 'CONTAINER DATABASE', lo cual podemos verificar con el siguiente comando desde sqlplus :

SQL> show con_name

          
           CON_NAME 
    _________________
    
           CDB$ROOT

Si deseamos conectarnos a la base de datos de tipo 'pluggable' llamada  'pdborcl' , es necesario ejecutar la siguiente sentencia:

 SQL> ALTER SESSION SET CONTAINER=PDBORCL;

             Session altered
  
La base de datos contenedor o 'CDB$ROOT' contiene su propio 'system' y 'sysaux'.  Un aspecto curioso, es que los tablespaces 'undo' y 'temp' que contienen los datos para todas las 'pluggables databases',  van a residir en la base de datos contenedor. Aunque es la configuración  por default, puede ser modificada.

De la misma forma, solo van a existir los 'redo logs' únicamente en el contenedor, por lo que podriamos tener transacciones de diferentes bases de datos concentrados en estos. Sería interesante validar en un futuro, si esto no va a provocar problemas de contención en disco. El archivo de control o 'control file' únicamente va a existir en la base de datos contenedor.

Las 'pluggable databases' van a tener sus propios tablespaces 'system' , 'sysaux' y de datos. Se puede conocer su estatus por medio de la siguiente consulta a la vista dinámica 'v$pdbs':

 SQL> SELECT name, open_mode FROM v$pdbs;

  NAME                             OPEN_MODE
 --------------------------        ----------------
 PDB$SEED                       READ ONLY
 PDBORCL                        READ WRITE

Por medio de la siguiente consulta podemos conocer que parámetros son modificables a nivel 'pluggable database'.

SQL> SELECT substr(NAME,1,30), substr(value,1,30) FROM V$SYSTEM_PARAMETER
   where ISPDB_MODIFIABLE ='TRUE'
      ORDER BY NAME;


Adicionalmente,  sera obligado familiarizarnos con el 'package' : 'dbms_resource_manager' para modificar parámetros de las 'pluggables databases'.

En versiones anteriores a 12c,  cuando requeriamos clonar una base de datos a un ambiente diferente, utilizabamos el comando 'ALTER DATABASE BACKUP CONTROLFILE TO TRACE AS .....'.  que contenia principalmente la lista de 'redo logs' y 'datafiles' de la base a clonar, no importando que esta se encontrara en estado 'OPEN'.

En 12c,  ya no podremos utilizar este comando para clonar, ya que las 'pluggable databases' no tienen 'control file' !! ... únicamente se tiene el 'control file' para la base de datos 'CONTAINER'.  Para exportar la definición de la 'pluggable database'  es necesario que esta se encuentre en modo read only:

  SQL> alter database open read only;

La definición de la 'pluggable database'  se exporta en formato 'XML' con el siguiente comando:

SQL> BEGIN
         DBMS_PDB.DESCRIBE(
            pdb_descr_file => 'c:\orcl\pdborcl.xml');
        END;
    /


Otra forma de exportar la metada a un archivo 'XML ' es por medio del siguiente comando:

SQL> ALTER PLUGGABLE DATABASE pdborcl UNPLUG INTO 'C:\orcl\pdborcl.xml';

Pluggable database altered.

Sin embargo hay que ser cuidadosos con él comando 'UNPLUG', ya que una vez ejecutado,   no es posible realizar ningún operación sobre la 'pluggable database'.  Si queremos dar de baja  la base 'pdborcl' recien 'desconectada' nos va a enviar el siguiente mensaje:

SQL> shutdown immediate
ORA-65086: no se puede abrir/cerrar la base de datos de conexi¾n


De la misma forma no podemos abrir la base de datos:

SQL> startup
ORA-65086: no se puede abrir/cerrar la base de datos de conexi¾n


Si ejecutamos el comando 'UNPLUG' y resulta que realmente no deseabamos 'desconectar' la base de datos y queremos realizar un 'PLUG IN', de la base de datos, veremos que al parecer no existe o no es necesario un comando para realizarlo la 're-conexión.'  

Para volver a regenerar la base de datos 'pdborcl' en el mismo 'container' donde realizamos el 'unplug', tenemos que borrar la base de datos 'pdborcl', teniendo cuidado de no borrar los 'datafiles', con el siguiente comando:

SQL> DROP PLUGGABLE DATABASE pdborcl  KEEP DATAFILES;

Pluggable database dropped.

Con el siguiente comando recreamos las base de datos 'pdborcl' a partir de la metadata contenida en el archivo 'pdborcl.xml', con lo que ya tendriamos disponible nuevamente la base de datos 'pdborcl'

SQL>CREATE PLUGGABLE DATABASE pdborcl USING  'C:\orcl\pdborcl.xml'  COPY TEMPFILE REUSE;

Pluggable database created.

En 12c clonar una base de datos 'pluggable' dentro de la misma instancia es mucho más rápido y sencillo que en versiones anteriores.  Vamos a clonar la base de datos 'pdborcl' a una nueva llamada 'pdbventas' utilizando la opción 'FILE_NAME_CONVERT'.  Esta claúsula funciona por pares, es decir los 'datafiles' contenidos en el directorio de la base de datos origen  'c:\pdborcl1\' van a ser copiados al directorio de la base destino o clonado  'c:\pdbventas1\'.   Con el siguiente comando creamos la nueva base de datos 'pdbventas' en apenas unos segundos.

SQL> CREATE PLUGGABLE DATABASE PDBVENTAS FROM PDBORCL
           FILE_NAME_CONVERT =('c:\pdborcl1\', 'c:\pdbventas1\');

Pluggable database created.
 

Si por ejemplo intentamos clonar sin especificar su par para el directorio 'c:\pdborcl2\', recibimos el siguiente mensaje 

SQL> CREATE PLUGGABLE DATABASE PDBROCL FROM PDBVENTAS FILE_NAME_CONVERT
           =('c:\pdborcl1\', 'c:\pdbventas1\', 'c:\pdborcl2\' );

         CREATE PLUGGABLE DATABASE PDVENTAS FROM PDBORCL FILE_NAME_CONVERT =('c:\pdborcl1\', 'c:\pdbventas1\', 'c:\pdborcl2\' );
                                                                              
    *
ERROR at line 1:
ORA-02000: falta la palabra clave ,

Con esto finalizamos un pequeño vistazo a esta nueva versión. Habra que familiarizarse con nuevos comandos para clonar, crear, respaldar y recuperar base de datos en 12c.

Conclusiones

La nueva funcionalidad 'MULTITENAT' es una de las más atractivas de la nueva versión Oracle 12c. Permite optimizar el uso de recursos, al eliminar la necesidad de tener varias instancias en un solo equipo. La generación de nuevas bases de datos es un proceso mucho más rápido y sencillo que en versiones anteriores. 

Se podrá tener un control centralizado de las diferentes bases de datos a partir de un contenedor principal. La administración de usuarios tambien observa cambios,  ya que tendremos usuarios comunes o 'common users' , consolidación de esquemas  o 'schema consolidation'.  Se tendrán también reubicación de 'datafiles' en línea,  una nueva infraestructura para 'RAC' llamada 'Flex Cluster' , alta redundancia para la instancia de 'ASM'  llamda 'Flex ASM',  tener más de un índice sobre una misma columna, entre otras nuevas funcionalidades.

Saludos !

José Manuel Vizcaíno Culebra

Contacto servicios profesionales:

jose.vizcainoculebra@gmail.com

5532439143 Ciudad de México

No hay comentarios.:

Publicar un comentario