Llegamos a ustedes gracias a:



Reportajes y análisis

Oracle Database 12c: Una base de datos de nube

[22/07/2013] Con un desarrollo de casi cuatro años, Oracle Database 12c introduce tantas nuevas capacidades en tantas áreas -consolidación de base de datos, optimización de búsqueda, afinamiento de rendimiento, alta disponibilidad, particionamiento, respaldo y recuperación- que un análisis en profundidad tendrá igual esquinas que pulir. Por ello, además de cubrir los grandes temas, les daremos una serie de mejoras menores como tarea.
Habiendo trabajado en la beta por muchos años, puedo decirles que la cantidad de software es también impresionante, comenzando con una suave instalación en clúster RAC. Como con cualquier nuevo lanzamiento de software, encontré unos cuantos errores menores. Afortunadamente han sido resueltos en la versión de producción.
Bases de datos conectables
La consolidación es una estrategia de negocio importante para reducir los costos de los gastos de infraestructura y funcionamiento. En muchos servidores de base de datos de producción, una gran parte de los ciclos de CPU no se utilizan. Mediante la consolidación de muchas bases de datos en menos servidores de bases de datos, el hardware y el personal de operaciones pueden ser utilizados más eficazmente.
Pero en consolidación de bases de datos es más fácil hablar que hacer. Los temas críticos tales como las características de carga de trabajo de la base de datos, la capacidad de mantener los niveles de servicio de rendimiento y las necesidades de recuperación de punto-en-el-tiempo de las diferentes bases de datos, deben ser considerados durante los esfuerzos de consolidación. Lo ideal sería que la consolidación no solo reduzca la necesidad de adquirir y asignar menos CPU física, memoria RAM e I/O (debido a los servidores físicos infrautilizados), sino que también reduzca el consumo real de recursos (porque varias instancias comparten algunos gastos generales). Sin embargo, en el pasado, hemos visto que la co-localización de las bases de datos físicamente en el mismo servidor no reduce el uso general de los recursos.
La nueva función de la base de datos conectable de Oracle reduce el riesgo de consolidación debido a que el DBA puede conectar o desconectar una base de datos existente a, o desde, una base de datos contenedor fácilmente. No hay necesidad de modificar el código de la aplicación. Cuando el usuario se conecta a una base de datos conectada, el entorno de base de datos se ve exactamente como si el usuario se hubiera conectado a una base de datos tradicional.
Además, las bases de datos conectables tienen un menor consumo de recursos. La memoria y los procesos son propiedad de la base de datos del contenedor y compartidas por todas las bases de acoplamiento activo, mejora el uso de recursos en general. También es fácil de desconectar una base de datos y convertir la base de datos conectable a una base de datos tradicional, si es necesario. Además, puede realizar copias de seguridad y recuperación de bases de datos conectables, independientemente de la base de datos del contenedor. También se puede realizar una recuperación de punto en el tiempo de una base de acoplamiento activo. Además, el Administrador de recursos se puede utilizar para controlar los recursos consumidos por una base de datos conectable.
En resumen, la consolidación de base de datos se puede hacer mucho más eficazmente que nunca antes, con bases de datos conectables. Finalmente, tenemos una base de datos de nube de verdad.
Características Optimizer
La versión 12c presenta una serie de características útiles SQL Optimizer, y la mayoría de ellas se activan automáticamente.
Aunque el Optimizer ha madurado en los últimos años, todavía no es raro que éste elija un plan de ejecución ineficiente debido a estimaciones incorrectas de cardinalidad, estadísticas no válidas, o estadísticas vencidas. Esto puede tener consecuencias nefastas. Una sentencia SQL estimada para correr en unos segundos puede tardar horas en ejecutarse si el plan de ejecución escogido no es el óptimo.
La retroalimentación de la cardinalidad -una característica introducida en la versión 11g- supervisa la ejecución de sentencias SQL y reoptimiza si la cardinalidad real, tales como el número de filas devueltas por la consulta, varía mucho de las estimaciones de cardinalidad. Una nueva característica de 12c, llamada Plan de Adaptación da el siguiente paso en auto-ajuste de SQL. En lugar de elegir el plan de ejecución final en tiempo de análisis, Optimizer difiere la elección final entre los sub-planes múltiples hasta el tiempo de ejecución.
Esencialmente, el Optimizer introduce un fragmento de código, bien llamado recolector de estadísticas (Statistics Collector), en la ejecución de SQL. El recolector de estadísticas hace un buffer de las filas de los pasos previos en el plan de ejecución. Dependiendo del número de filas recuperadas, Optimizer elige el plan de ejecución final. El plan elegido se volverá a utilizar para las ejecuciones posteriores de la sentencia, si el cursor es compartido. ¡Un optimizador just-in-time!
La reoptimization adaptativa, similar a la función Retroalimentación de la Cardinalidad, solo afecta a las ejecuciones posteriores de una sentencia SQL. Si las estimaciones del Optimizer son muy diferentes a las estadísticas de ejecución, el optimizador utiliza las estadísticas de ejecución como un mecanismo de retroalimentación y vuelve a analizar la sentencia SQL durante la siguiente ejecución.
En general, la calidad de las estadísticas equivale directamente a la calidad de los planes de ejecución generados por el Optimizer, a pesar de los bugs. En la versión 12c, si la calidad de las estadísticas disponibles no es suficiente, entonces el optimizador puede muestrear dinámicamente las tablas para recolectar estadísticas. Esta recopilación de estadísticas dinámica utiliza los mismos métodos como el muestreo dinámico disponible en las versiones anteriores, excepto que, en la base de datos 12c, estas estadísticas también se almacenan para su uso futuro.
Características de rendimiento
La versión 12c introduce numerosas mejoras de rendimiento. Vamos a revisar solo algunas de las más importantes.
Tradicionalmente, las consultas con unión o la unión de todas las ramas, se ejecutan una tras otra; lo que significa que una rama de la unión o la unión de todas es ejecutada, seguida por la siguiente rama y así sucesivamente. La versión 12c introduce la ejecución concurrente de ramas de unión, lo que significa que un conjunto de servidores en paralelo ejecutará una rama, un segundo conjunto de servidores en paralelo ejecutará una rama de todas las uniones, y así sucesivamente, todo al mismo tiempo.
Esta característica de ejecución concurrente será muy útil si la mayor parte del tiempo de ejecución de las consultas se empleara fuera de la base de datos, como cuando se espera un mensaje SQL*Net desde un enlace de base de datos remoto o una respuesta de llamada SOA. El uso efectivo de esta nueva característica podría reducir drásticamente el tiempo de espera, mejorando el tiempo transcurrido de SQL. (Por cierto, con la versión 12c, los paquetes SQL*Net se pueden comprimir para el tráfico de base de datos, ayudando a reducir la latencia en un entorno de red WAN).
Un problema clásico con el paralelismo es que todos los servidores paralelos necesarios para una operación pueden no estar disponibles en el momento de la iniciación de sentencia paralela, lo que lleva a que las sentencias paralelas se ejecuten en un número menor de servidores en paralelo. La cola de sentencias paralelas -una característica introducida en la versión 11.2- resolvió el problema poniendo en cola las sesiones cuando no estaban disponibles los suficientes servidores paralelos. Con la base de datos 12c el usuario puede construir varias colas de sentencias paralelas utilizando el gestor de recursos de base de datos, omitir la puesta en cola de sentencias paralelas cuando se trata de sentencias críticas, y agrupar múltiples sentencias paralelas juntas para reducir el tiempo de espera en las colas de las sentencias paralelas.
Otra de las novedades en la versión 12c es que se pueden crear varios índices en el mismo conjunto de columnas. Por ejemplo, el usuario puede crear índices de bitmap y b-tree en el mismo conjunto de columnas, o inclusive crear un índice único y no único en el mismo conjunto de columnas. Los índices múltiples son de utilidad cuando se necesita convertir un índice de un tipo en otro tipo, o convertir un índice particionado a uno no particionado, o viceversa, con un tiempo mínimo de inactividad. Por supuesto, el usuario puede elegir mantener varios índices en el mismo conjunto de columnas de forma permanente, también.
Alta disponibilidad
En la base de datos Oracle, la noción de servicio implica una propiedad de conexión especificada para conectarse a una instancia deseada. Utilizamos comúnmente servicios para equilibrar la carga de trabajo entre las instancias de un Clúster de Aplicación Real, por ejemplo. La versión 12c introduce Global Data Services, los cuales balancean la carga de trabajo no solo entre las instancias, sino entre las bases de datos.
Imagine un entorno global en el que se utilizan diferentes bases de datos para servir a diferentes segmentos de usuarios. Por ejemplo, una base de datos en Nueva York sirve a los usuarios en la costa este, mientras que una base de datos en San Francisco sirve a los usuarios en la costa oeste, y ambas bases de datos están sincronizadas por el software de replicación. En la base de datos 12c, los servicios son verdaderamente globales y se utiliza un equivalente del conocido escucha SCAN (Single Client Access Name), llamado Global Data Listener,
Para redireccionar la conexión de la aplicación a una base de datos que pueda servir mejor al cliente. Esta característica también mejora la disponibilidad porque las nuevas conexiones a bases de datos fallidas pueden redirigirse rápidamente a una base de datos de supervivencia.
Después de que un servicio falla hacia otra instancia, las aplicaciones usualmente no saben el estado de las transacciones en vuelo. Aunque los cambios hechos por una transacción comprometida son permanentes, como señalan las propiedades ACID de la base de datos Oracle, los mensajes de estado de compromiso a la aplicación tienen un carácter transitorio. El resultado es que una falla de instancia crea un dilema clásico: Si la aplicación reprograma una transacción fallida entonces los cambios pueden perderse de forma permanente.
La base de datos 12c resuelve este dilema con el protector de transacciones (Transaction Guard), una nueva función que mantiene el estado de la operación de forma permanente. Transaction Guard asigna un ID de transacción global única para cada transacción, y mantiene el estado de la transacción global por un período predefinido de tiempo. Después de una falla, la aplicación puede volver a consultar el estado de una transacción y tomar medidas correctivas de manera determinista.
Oracle no se detuvo en el mero suministro de un mecanismo para identificar el estado de la  transacción. La versión 12c también introduce continuidad de la aplicación. Con esta función, un nuevo controlador de reproducción del lado del cliente recuerda sentencias SQL presentadas; y después de la detección de fallas, las sentencias se repiten para insertar transacciones fallidas en la base de datos. Sin embargo, tenga en cuenta que los cambios de código pueden ser necesarios para integrar de forma segura el controlador de reproducción con la aplicación.
Mejoras de particionamiento
Ningún lanzamiento de base de datos está completo sin mejoras de particionamiento y la versión 12c no es la excepción.
Tradicionalmente, los índices se crean en todas las particiones de una tabla con particiones. La versión 12c presenta indexación parcial, lo que le permite crear índices en un conjunto parcial de particiones. Por ejemplo, si tiene particiones p1, p2, p3 ... p10 en una tabla, podría optar por crear un índice en las particiones p1, p2 y p3 solamente, y no crear índices en las otras particiones. Esta función será útil en esquemas de particionamiento variantes en el tiempo, por lo general en el que las particiones más antiguas mayormente solo son consultadas; mientras que las particiones más nuevas son actualizadas en gran medida.
Podemos reducir la carga de trabajo de transacciones mediante el aplazamiento de los índices en las particiones intensivas en transacciones. El usuario también puede construir nuevos índices con múltiples pasos para reducir los problemas de bloqueo y el consumo de recursos asociados con la reconstrucción tradicional de índice. Por supuesto probablemente habrá adivinado, la poda de particiones es un requerimiento clave para que Optimizer elija los índices parciales; y los índices parciales no son soportados por índices únicos.
Los índices globales causan problemas para las operaciones a nivel de partición. Por ejemplo, si se elimina una partición, a continuación, un índice global en esa tabla debe ser actualizado. Mientras que los comandos de partición drop/truncate son rápidos (ya que son operaciones DDL), las actualizaciones a las entradas de índice global son más lentas, conduciendo a problemas de disponibilidad durante las operaciones DDL. Por esta razón, la versión 12c desacopla el mantenimiento de índice global de la ejecución de índice DDL. Así, solo la metada de índice global es actualizada durante la operación DDL de partición, y el mantenimiento real de índice puede ser aplazado para después. Un nuevo trabajo programado le permite borrar las entradas caducadas del índice global a las, digamos, 2 a.m., mejorando la viabilidad de los índices globales en tablas críticas.
También en Database 12c, la partición de referencia ahora trunca particiones dependientes. Con un esquema de particionamiento de referencia, las tablas en ambos extremos de una restricción de referencia son particionadas a lo largo de los mismos límites de la partición. A partir de la 12c, truncar o dejar una partición de tabla llevará en cascada hacia la partición de tabla dependiente.
Backup y recuperación
Tradicionalmente, la restauración de una sola tabla es un proceso complicado que implica una restauración de tablas, exportando la tabla restaurada desde el espacio de tabla restaurado, y luego importándola hacia la base de datos de producción. El nuevo comando de restauración de tabla en Recovery Manager (RMAN) simplifica esta tarea.
La re-creación de instancias de una base de datos primaria a un sitio provisional o un sitio de Data Guard es un gran problema para sitios VLDB (Very Large Database - base de datos muy grande), especialmente si la base de datos está separada por miles de kilómetros. Antes de Database 12c, RMAN no soportaba compresión nativa durante la duplicación activa y así, generalmente, los DBAs reordenaban hacia otro método de restauración desde el backup, tal como copiar los archivos a través de la red mediante un canal comprimido, o inclusive enviando una cinta. En Database 12x, RMAN soporta copias de archivos de datos sobre la red con compresión. Esta función facilitará los esfuerzos de clonación de bases de datos tremendamente. También, el comando Active Duplicate soporta compresión de red durante la transferencia de datos, permitiendo clones más rápidos directamente desde la base de datos de producción.
La ejecución de sentencias SQL desde la línea de comando RMAN no es solo es difícil de manejar, sino que la sintaxis no es precisamente amigable. La versión 12c mejora la línea de comandos de RMAN para que pueda ejecutar sentencias SQL de forma nativa en RMAN sin necesidad de la cláusula SQL adicional.
También puede realizar copias de seguridad y restauraciones de plataforma cruzada en Database 12c sin necesidad de convertir explícitamente endianness de archivos de bitácora de archivamiento, porque podría simplificar enormemente las migraciones entre plataformas con diferentes endianess. Sin la capacidad de convertir los endianess de archivos de bitácora y archivamiento, hay que recurrir a productos de replicación como Golden Gate, para reducir el tiempo de inactividad de la base de datos durante la migración de plataforma.
Beneficios diversos
Además de las mejoras más importantes descritas anteriormente, Database 12c presenta muchas mejoras relativamente menores que serán importantes para los DBA. Éstas son algunas de las más notables.
Refresco de la vista materializada. Actualizaciones no atómicas de una vista materializada puede afectar el rendimiento de las consultas de usuarios debido a la necesidad de mantener la consistencia de lectura. Borrar sentencias se usa para actualizaciones no atómicas, así que si otra consulta SQL accede la vista materializada en forma concurrente, entonces la consulta sufrirá problemas de rendimiento, porque la consulta debe utilizar una enorme cantidad de registros de deshacer para reconstruir bloques consistentes de lectura. La versión 12c introduce una nueva optimización, así que en lugar de borrar desde la tabla original, una nueva tabla idéntica es llenada con datos refrescados. Al completar el refresco, las tablas son cambiadas, de esta forma se completa el refresco fuera-del-lugar. Los usuarios pueden consultar la tabla original sin incurrir en ninguna sobrecarga adicional. Esta estrategia ofrece conveniencia operativa para refrescar la vista materializada con mínimo impacto.
Soporte IPv6. Muchas organizaciones se están preparando para certificar la compatibilidad con IPv6 ya que el espacio de direcciones IPv4 se está agotando. Database 12c soporta IPv6 para las direcciones de red pública. No es compatible con IPv6 en direcciones de red privada, pero es probable que no sea un problema.
Actualización en paralelo. Esta es una característica que he estado buscando durante muchos años. En entornos de alta disponibilidad, mantener la base de datos apagada para una actualización, aún de unas cuantas horas, tiene un costo prohibitivo. Actualizaciones sucesivas no siempre son posibles para las principales actualizaciones de software de bases de datos, y siempre es una aventura arriesgada afinar el Database Upgrade en sí. La versión 12c utiliza paralelismo para mejorar el tiempo de inactividad por la actualización.
Archivos de passwords en ASM.  Otra característica importante en Database 12c es la capacidad de almacenar archivos de passwords en ASM (Automatic Storage Management). En RAC, cambiar las contraseñas de los usuarios privilegiados es una tarea engorrosa. Incluso con el uso de NFS u otro sistema de archivos compartidos para el archivo de contraseña, las garantías deben ser ejecutadas en todas las instancias. En Database 12c, los archivos de contraseñas se almacenan en ASM -y las garantías tienen que ser ejecutados en una sola instancia.
La riqueza de las nuevas características de Oracle Database 12c ofrece a las instalaciones de Oracle muchas razones para considerar la actualización. Si administra una base de datos de nube, o si desea mejorar la utilización de los recursos mediante la consolidación de múltiples bases de datos en hardware compartido, debe considerar la actualización lo antes posible. La nueva característica de bases de datos acoplables es extremadamente útil para co-ubicar múltiples aplicaciones en una sola instancia de base de datos.
Si clona frecuentemente bases de datos sobre una WAN, entonces debería considerar la actualización para aprovechar la compresión nativa RMAN cuando se transfieren los archivos. Si su empleador dictamina soportar el protocolo IPv6, entonces debería considerar una actualización. Además, los sitios que hacen uso de numerosas vistas materializadas pueden beneficiarse de los nuevos métodos de actualización disponibles en la nueva versión.
Y por último, si está actualmente en el proceso de diseño o el desarrollo de una aplicación con enfoque de alta disponibilidad, entonces debe darle una mirada a las funciones Transaction Guard y Application Continuity introducidas en 12c.
Riyaj Shamsudeen, InfoWorld (EE.UU.)