Dicho evento se viene realizando anualmente desde hace seis ediciones (por lo menos en Uruguay), y cuenta con el apoyo del grupo de usuarios Oracle del Uruguay - UYOUG -, la misma Universidad y del Ministerio de Educación y Cultura; además de Tilsor y Quanam, partners de Oracle aquí.
En él, durante cada año se conforma una gira por varios países del continente donde se realizan speeches y talleres prácticos de corte técnico y de actualización sobre productos y servicios que ofrece Oracle (Oracle, MySQL, Java, etc.), brindados por reconocidos Oracle ACEs regionales e internacionales.
Personalmente, desde el año pasado que estaba con ánimo de participar, pero por motivos ajenos a mi voluntad no pude hacerlo. Este año tuve la revancha y me dirigí a ver de qué se trataba el evento, ya que se orienta a profesionales vinculados a las áreas de DBA, TI y desarrollo, principalmente.
La verdad es que quedé sorprendido para bien por el buen nivel del evento en general, principalmente por la jerarquía y experiencia de los oradores, así como la practicidad al explicar conceptos un poco difíciles de asimilar que se introducen en las actualizaciones que se vienen dando.
Las charlas y talleres este año giraron en torno a la más reciente versión mayor de la BD Oracle, la 12c; además de los nuevos conceptos que se introducen con el trabajo en la nube.
El principal concepto que se introdujo en la 12c es el de Multitenant y según parece viene a significar en un cambio de paradigma en cuanto a su administración y funcionamiento.
Multitenant
Multitenant se basa en un cambio de arquitectura de las bases de datos, en donde se implementa una base de datos contenedora, que viene a ser una base de datos "raíz"; sobre las que trabajan todas las bases de datos pluggables que se dispongan (hasta 252 en la 12.1). Estas PDBs se pueden attachear o desattachear en pocos pasos, sin necesidad de exportar ni realizar otras tareas para enviarlas a otro servidor.
En la base de datos raíz ahora se pasa a alojar la metadata del SGBD (esquemas, tablas, secuencias, etc. del sistema).
En tanto, en las PDBs (pluggeable databases) se almacena la metadata propia de la aplicación, así como los objetos que contienen los datos de la aplicación en esa BD.
Este cambio de arquitectura trae varias ventajas como ser:
- Posibilidad de transportar una PDB de un container a otro de manera muy limpia y fácil (incluso en sistemas con distinto endianness).
- Fácil clonación de BDs. Éstos últimos dos items son de gran ayuda por ejemplo en el caso de copia de bases de desarrollo a producción.
- Unificación de diversas tareas de administración, recovery, upgrade, etc., ya que se realizan ahora sobre la base raíz.
- Unificación de recursos de BDs: Bajo este esquema se comparten por ejemplo redo, undo logs y la SGA, donde el SGBD comparte y gestiona la memoria y los procesos background de todas las bases de datos en la container.
Datos de interés de Multitenant
- Si bien no es necesario tener una licencia especial para utilizar este tipo de arquitectura con 12c, para poder tener más de una PDB en un container se debe tener paga la opción de Multitenant.
- Para poder pluggear una BD con versión anterior a 12c a una BD raíz, se debe anteriormente actualizar a 12c.
- Para poder actualizar de una versión anterior a 12c, existen varios métodos disponibles, por lo que se debe elegir cual es el método de conveniencia: http://www.oracle.com/technetwork/database/upgrade/upgrading-oracle-database-wp-12c-1896123.pdf
- Una vez que se migra a 12c, no se puede hacer downgrade de una PDB hacia una base de datos standalone. En este caso se debe pensar en algún método alternativo como un export por ejemplo.
- A efectos de upgrade, instalación, ejecutar scripts de mantenimiento, etc; Oracle recomienda utilizar el PERL script catcon.pl. Este script, que tiene una cantidad grande de parámetros y utilidades, se debe correr con el ejecutable perl que se dispone en los binarios del SGBD.
- En la versión 12.2 se va a eliminar la posibilidad de utilizar BDs standalone. En su lugar se deberá implementar una BD single-tenant.
In Memory Database
Otra característica importante que se incluye a partir de la versión 12.1 (no de la 12.0), es la funcionalidad In Memory.
Esta función permite que fragmentos o la totalidad de una base de datos trabaje en memoria para conseguir una mejora de performance significativa en cuanto a consultas.
El funcionamiento a grandes rasgos consiste en el almacenamiento de los datos de cada tupla ,paralelamente, en un formato columnar. Bajo este precepto, y como el motor de base de datos en cada consulta recorre campo por campo de una fila hasta llegar al requerido,al estar los datos de una sola columna alojados en una fila, las que consultas que levantan gran cantidad de datos experimentan una mejora sustancial en el tiempo que insumen.
Esto es particularmente útil por ejemplo si se desea mantener un ambiente transaccional en la misma base de datos que se utiliza para reportes, sin perjudicar mayormente la performance del sistema productivo.
Las estructuras In Memory se alojan en una nueva área de memoria dentro del servidor destinada para las mismas.
Además incluye varios niveles de compresión en cuanto a los datos alojados en esta área reservada, dependiendo la rapidez que se quiera obtener, de manera que el aumento de uso de memoria respecto a si no se utiliza esta funcionalidad ronda en un 20% aproximadamente.
Teniendo en cuenta las ventajas en cuanto arquitectura, y además que el acceso a memoria es bastante más rápido que el de disco duro, supone una mejora drástica.
Fuentes
Instructivo de actualización a 12c
Multitenant
In Memory
Resumen
Es totalmente recomendable anotarse a estos eventos de OTN, ya que ofrece un pantallazo de lo que está a la vanguardia en cuanto al mundo Oracle.
Además es para tener en cuenta la actualización a 12c por todas las funcionalidades y mejoras que incluye, además de ser la versión que estará siendo referenciada en el mediano plazo.
No hay comentarios:
Publicar un comentario