Oracle Database 12c: Database Resource Manager
Por
Durante varios años hemos venido sufriendo el desagradable e involuntario desperdicio de hardware en nuestros servidores cuando nuestra organización maneja grandes cantidades de bases de datos. Hace mucho tiempo se utilizaba un servidor para cada una de nuestras bases de datos, entonces, teníamos al final el servidor “A” para la base de datos de contabilidad, el servidor “B” para la base de datos de Recursos Humanos, y así sucesivamente. El problema con este enfoque es que desperdiciamos hardware. No necesariamente la base de datos de contabilidad va a utilizar el 100% de los recursos del servidor “A” y lo mismo podríamos decir de la base de datos de Recursos humanos en el servidor “B”, por lo tanto, durante el tiempo que dichas bases de datos no están haciendo uso de ese hardware, podríamos decir que el
hardware está desperdiciándose.
Ante este problema muchas empresas tomaron otro enfoque, entonces consolidaron varias bases de datos dentro de una sola, creando un esquema por cada base de datos, esto con el objetivo de que la única base de datos pudiera tener toda la carga de trabajo del negocio y así poder hacer uso al máximo del servidor donde vaya a alojarse, para esto necesitábamos entonces, un servidor robusto que pudiera hacer frente a esa carga de trabajo. Esto dio resultado a otro problema, manejar los objetos provenientes de las distintas bases de datos se volvió difícil, habían esquemas con el mismo nombre, incluso objetos con el mismo nombre y tipo, por lo tanto la consolidación a nivel de bases de datos era muy complicada y no siempre
los recursos del servidor respondían de acuerdo a las solicitudes de carga de trabajo de los diferentes esquemas, sin mencionar, que la aplicación era sumamente afectada debido a los cambios realizados en los esquemas. Surgió entonces, un nuevo enfoque: La consolidación a nivel de
servidores.
La consolidación de servidores eliminó por completo el conflicto entre esquemas que surgía al intentar consolidar los objetos de todas las bases de datos, pues en este enfoque varias bases de datos se alojaban en un mismo servidor, es decir, cada servidor tenía varias bases de datos. Por ejemplo la base de datos de contabilidad y la base de datos de Recursos Humanos se alojarían en el servidor “A” o en el servidor “B”, de esta manera algunas organizaciones aprovecharon los servidores que quedaron sin uso y los utilizaron en configuraciones de alta disponibilidad tipo “Activo-Pasivo” o “Activo-Activo”. Este enfoque, lamentablemente, dio lugar a que los recursos del servidor no fueran proporcionados adecuadamente dentro de las bases de datos que alojaba, y también, se desperdiciaban recursos en el software al duplicar N-1 veces la Instancia de la base de datos y procesos de fondo, donde N es el número
de bases de datos en el servidor.
Hasta aquí estos problemas habían sido enfrentados por los administradores de bases de datos y los administradores de los servidores. Oracle, por supuesto, trató de apoyar agregando diferentes funcionalidades a través de todas sus versiones hasta la versión 11g. En Oracle Database 12c, Oracle nos sorprende con una nueva arquitectura: La arquitectura “Multitenant”. Esta nueva arquitectura nos permite utilizar lo mejor de todos los enfoques, pues nos permite consolidar todas la bases de datos de nuestro negocio dentro de una sola base de datos, no hay desperdicio de recursos a nivel de software pues solo una instancia de base de datos es necesitada y no se desperdician los recursos de hardware pues existe “Oracle Database Resource Manager” para distribuir dichos recursos adecuadamente dentro de todas las bases de
datos consolidadas.
Es un grupo que constantemente está colaborando con la comunidad Oracle mediante artículos, conferencias, webinars y cursos de Oracle Database. Cuenta con varios miembros con el grado de “Oracle Certified Master” y “Oracle ACE”.
5
Articulo especial
Base de datos