Administración de la Calidad del Servicio de Base de Datos Oracle - QoS

Transcripción

1 Newsletter Diciembre 2014 Edición Trimestral Contenido Página: Administración de la Calidad del Servicio de Base de Datos Oracle - QoS 1 Administración de la Calidad del Servicio de Base de Datos Oracle - QoS 5 Oracle Database In- Memory Editores Generales Francisco Barrundia 5a. Ave. Alejandro 5-55 Zona14,Edificio Lau Euro Plaza Torre II, Nivel 12 Teléfono: (502) Fax: (502) Débora Morán .info@datum.com.gt Por Ing. Alejandro Lau Pagina 1/10 alau@datum.com.gt Autores Contribuyentes Alejandro Lau Emilio Méndez En inglés se le conoce como Oracle Database Quality of Service Management (abreviado Database QoS). Consiste en un producto basado en políticas que supervisa las solicitudes de carga de trabajo en un sistema integrado. Esto se vuelve muy importante con la consolidación de bases de datos, en la cual se manejan bases de datos en cluster, en vez de servidores individuales por aplicación. Se hace necesario clasificar y dar prioridad a las distintas cargas. De este modo, en situaciones de recurso limitado o insuficiente, se puede dar más recurso a las tareas más críticas, sacrificando el desempeño de las tareas menos críticas. Otra función de este producto es detectar cambios en el rendimiento o cuellos de botella y asignar recursos para aliviar rápidamente la caída del rendimiento. Página 1

2 Beneficios de Usar Database QoS Ayuda a lograr los niveles de servicio esperados (SLAs). Reduce los requerimientos de tiempo y experiencia para los administradores de RAC. Ayuda a reducir las caídas de rendimiento, dando más estabilidad durante cambios de carga. Reduce el tiempo de resolución de problemas relacionados con rendimiento de aplicaciones. Agregar o eliminar servidores es transparente a las aplicaciones. Reduce el impacto provocado por la caída de servidores. Cómo Funciona Database QoS? 1. Por medio de una política creada por el administrador QoS: a. Asigna nueva carga a una Clase de Rendimiento, según atributos de la carga. b. Determina los tiempos de respuesta esperados (Objetivo de Rendimiento) de cada Clase de Rendimiento. c. Determina qué Clases de Rendimiento son las más críticas del negocio. 2. Monitorea el uso de recursos y tiempos de espera para todas las Clases de Rendimiento. 3. Genera recomendaciones de reasignar recursos para mejorar el rendimiento de una Clase de Rendimiento que está excediendo su Objetivo de Rendimiento. Además, muestra un análisis predictivo del impacto en todas las Clases de Rendimiento, si se implementa la recomendación. 4. Implementa las recomendaciones a solicitud del administrador de QoS. Luego evalúa que Clase de Rendimiento esté dentro de su Objetivo de Rendimiento. Database QoS y Server Pools Se pueden crear grupos de servidores dentro de un cluster (server pools) para separar los tipos de carga. Database QoS puede recomendar que se mueva un servidor de un grupo a otro, según la demanda proyectada. Database QoS también puede reubicar servidores para mantener los Objetivos de Rendimiento. Database QoS y Servicios En un cluster Oracle RAC, Database QoS monitorea los server pools y nodos en los cuales corren los servicios. Un servicio puede correr solo en un server pool. Entonces se monitorea la carga de clientes y aplicaciones que se conectan a la base de datos a través de servicios manejados por Oracle Clusterware. Las conexiones deben usar OCI o JDBC. Deben usarse servicios con la propiedad "load balancing advisory" como SERVICE_TIME y "load balancing goal" como LONG. Policy Sets El concepto central en Database QoS es el Policy Set. Un Policy Set se compone de: Recursos Restricciones para disponibilidad de recursos Clases de Rendimiento (cargas) Una o más Políticas de Rendimiento que especifican el Objetivo de Rendimiento para cada Clase de Rendimiento Página 2

3 Solo una Política de Rendimiento dentro del Policy Set puede estar activa a la vez. Se pueden activar las políticas en respuesta a requerimientos específicos usando un calendarizador, ventanas de mantenimiento, eventos, etc. Al crear un Policy Set se escogen los server pools que serán manejados por Database QoS. También se definen Clases de Rendimiento. Luego se crea una Política de Rendimiento para indicar qué Clases de Rendimiento tienen más prioridad y los Objetivos de Rendimiento de cada clase. Por ejemplo, se puede crear una política que administre las cargas durante horas hábiles (Business Hours Policy). Baje esta política se da más prioridad a las aplicaciones de compras de productos o servicios, así como a la aplicación de facturación. En cambio, las aplicaciones de recursos humanos y ERP tienen menos prioridad. Durante otros horarios y fin de semana, podemos definir otras políticas que dan más prioridad a otras aplicaciones y por lo tanto administran los recursos disponibles de distinta forma. Server Pools Al momento de decidir cuánto recurso a nivel de servidores y clusters necesitamos para el negocio, debemos sopesar dos aspectos: 1. Ahorro en costos al consolidar servidores y bases de datos. 2. Riesgo de que una aplicación o carga afecte el desempeño de otras aplicaciones, por el hecho de compartir recursos. Con server pools se logra dividir lógicamente los clusters, consolidación de recursos físicos y a la vez se mantienen aisladas las distintas clases de carga, con un rendimiento estable en nuestras aplicaciones críticas. Como vemos en el ejemplo, se tienen varios server pools para las aplicaciones del negocio. Las cargas se asignan a cada server pool por medio de la creación y asignación de servicios. El servicio Sales se considera el de más prioridad en este ejemplo y no comparte recursos con otros servicios. El servicio AP comparte recursos con el servicio AR. Por aparte, los servicios HR Y OS también comparten recursos. Página 3

4 Según las prioridades asignadas y el monitoreo de rendimiento, en algún momento puede haber movimiento de uno o más servidores de un pool a otro. En este ejemplo hay un pool de servidores libres que serían los primeros candidatos a incorporarse a otro pool que requiera más recurso. También es posible mover servicios de un pool a otro. TIP TÉCNICO DEL MES: ORA-00955: name is already used by an existing object (El nombre está siendo usado por un objeto existente) Ejemplo: Cuando se está creando una tabla o un sinónimo. Causa: +Se está creando un objeto (sinónimo, usuario, tabla, etc.) con un nombre de otro objeto que ya existe en el esquema. Solución: +Dar un nombre único al objeto, si por ejemplo se tiene una tabla que se llama VENTAS, crear otra con un nombre VENTASM, o un nombre que sea único. Por Lic. Francisco Barrundia fbarrundia@datum.com.gt Página 4

5 Oracle Database In-Memory Por Ing. Emilio Méndez La característica de base de datos Oracle de Almacenamiento de Columnas en Memoria (In- Memory Column Store) que se encuentra a partir de la versión Oracle Database , ofrece un alto rendimiento para consultas que se utilizan en sistemas de almacenes de datos (Data Warehouse), sin comprometer el rendimiento de los ambientes OLTP, y también sin la necesidad de cambios a nivel de aplicación. Cuando hablamos de un alto rendimiento, estamos hablando principalmente de consultas que inicialmente tardaban horas, con esta opción pasan a ejecutarse en segundos. Este es el poder de la nueva característica de base de datos de Oracle de Almacenamiento de Columnas en Memoria (que para este artículo llamaremos IM), en donde los usuarios de la inteligencia de negocios no tendrán por qué esperar que los datos transaccionales sean movidos, así como también esperar que los objetos intermediarios de carga de datos sean creados. La opción de base de datos IM procesa las consultas en el mismo servidor de base de datos donde las transacciones están ocurriendo. Esto significa que el análisis de la inteligencia de negocios puede suceder literalmente en el momento de la transacción comercial en vez de ocurrir en algún momento posterior después de la transformación de los datos, ofreciendo al cliente, un análisis en tiempo real. La habilidad de realizar fácilmente análisis de datos en tiempo real en conjunto con el procesamiento de transacciones también tiempo real en todas las aplicaciones existentes, habilita a las organizaciones a transformar rápidamente los modelos de datos necesarios para los tomadores de decisiones en base a información de la inteligencia de negocio, con el objetivo de que respondan instantáneamente a las demandas del cliente y continuamente optimizar todos los procesos principales. Cabe mencionar que no es necesario cambiar la configuración de carga de trabajo mixta (OLAP, OLTP) inmediatamente, si se tiene la infraestructura de almacenamiento de datos que existe hoy en día (como por ejemplo discos de fibra canal y la configuración de RAID adecuada), se puede personalizarla característica de base de datos IM, aumentando el rendimiento de consultas en los sistemas de almacenamiento de datos. Esta característica de IM ofrece un alto rendimiento en memoria sin la necesidad de restringir funcionalidad o aceptar compromisos, complejidad y riesgo. Construyendo esta opción de Oracle Database In-Memory con una aplicación existente de base de datos Oracle es tan fácil como apagar o encender la luz, ya que no requiere cambios en la aplicación como tal. Página 5

6 Oracle Database In-Memory está completamente integrado con la escalabilidad de la renovada Oracle Database 12c, la capa de almacenamiento, disponibilidad y tecnologías de seguridad haciendo la base de datos más fuerte ofrecida en el mercado. Las plataformas que soportan esta opción de base de datos 12c son: Linux x86, Linux x86-64, Solaris SPARC (64-bit), Microsoft Windows x86, Microsoft Windows x64 (64-bit), IBM AIX on Power Systems (64-bit), Solaris x86-64 (64-bit). ARQUITECTURA "DUAL-FORMAT" La característica de base de datos Oracle IM optimiza ambos tipos de carga, para análisis de datos (OLAP) y transacciones mixtas(oltp), obteniendo un rendimiento excepcional para transacciones simultáneamente, así como soportando operaciones de analytics en tiempo real, inteligencia de negocios y reportes. Esta capacidad de avance está habilidad por la arquitectura "dual-format" de esta opción de base de datos IM. Desde ahora, las bases de datos fuerzan a los usuarios a almacenar datos ya sea a nivel de columna o a nivel de fila. Ilustración 1 - Arquitectura de la opción In-MemoryColumn Store. El formato de columna es altamente eficiente para analytics, pero impone largas sobrecargas cuando se usa en ambientes OLTP. Similarmente el formato de filas es extremadamente más rápido en sistemas OLTP, pero está menos optimizado para trabajar en sistemas de analytics. La única forma de optimizar para ambas cargas(oltp y OLAP) ha sido copiando los datos desde sistemas OLTP a sistemas OLAP, usando procesos complejos de ETL(Extract, Transform, Load) que agregan un gran consumo de recursos. La arquitectura de formato dual de base de datos Oracle IM, elimina esta utilización de recursos que usualmente representan las consultas sobre ciertas tablas cuando simultáneamente se usa el formato tradicional de filas y un nuevo formato de columna. El optimizador de SQL Oracle automáticamente realiza un ruteo de queries relacionados con OLAP al formato de columna y un ruteo de queries OLTP al formato de fila, de forma transparente, entregando el mejor rendimiento de ambas opciones. Oracle Database 12 automáticamente mantiene una consistencia transaccional completa entre los formatos de filas y columnas, tal y como mantiene la consistencia entre tablas e índices. Página 6

7 El nuevo formato de columna es un ambiente directamente relacionado a memoria. Las tablas son almacenadas en disco usando los formatos de Oracle existentes, basados en filas o formatos híbridos columnares. Muchos años de experiencia han demostrado que utilizando un porcentaje pequeño de bloques de datos en memoria, elimina la mayor cantidad de problemas en rendimiento de I/O. Por lo tanto la mayor parte de la capacidad de la memoria en un servidor de base de datos puede ser ubicada en el formato de columna. El formato en memoria de columnas de Oracle utiliza una compresión sofisticada para expandir la capacidad de la memoria y mejorar el rendimiento de los queries. Los ratios de compresión varían entre 2X y 20X, dependiendo de la opción escogida y la redundancia en la data. El método de compresión puede ser diferente a través de columnas, particiones o tablas. Por ejemplo, algunas particiones de tablas pueden ser optimizadas para escanear con rapidez, otras tablas para el consumo de memoria, mientras que otras pueden optimizar la eficiencia manejada frecuentemente por operaciones DML. OPTIMIZACIONES INTEGRALES DE IN-MEMORY La opción de Oracle Database In-MemoryStore Column tiene las siguientes optimizaciones integrales que se pueden trabajar en memoria, como por ejemplo: escaneos, joins en memoria, funciones de agregación en memoria. Los queries que se utilizan en analytics usualmente hacen referencia solo a un pequeño número de columnas en una tabla. Oracle Database IM minimiza la carga de trabajo y maximiza el rendimiento de la base de datos, accediendo únicamente a las columnas necesarias y procesando dichas columnas directamente sin tener que descomprimirlas primero. Las tablas son separadas lógicamente en secciones, y los valores máximo y mínimo de cada columna son almacenados para cada sección de la tabla. Eso permite que los queries rápidamente se salteen secciones de la tabla que únicamente contienen datos fuera del rango necesitado. Algunas columnas tienen muchos valores repetidos, como por ejemplo una columna que almacena la región geográfica, la cual tendrá muchas repeticiones de mismas regiones. Oracle Database IM comprime estos valores repetidos para ahorrar memoria y optimizar el procesamiento en la ejecución de las condiciones del query, solo una vez por cada valor de columna que vendría siendo uno por región. Los microprocesadores modernos soportan operaciones vectoriales SIMD (Single Instruction for Multiple Data) para acelerar las gráficas y la computación científica. Oracle Database IM puede usar estas instrucciones vectoriales SIMD para procesar múltiples valores de columnas en un solo ciclo de reloj de CPU. Los joins de tablas en memoria toman ventaja del nuevo formato de columna, convirtiendo las condiciones de joins en filtros aplicados durante los escaneos de datos. Mientras que los algoritmos de las funciones agregación en memoria aprovechan el formato de columna para acelerar los queries de las transacciones de analytics y los reportes que agregan grandes cantidades de datos. Juntas todas estas optimizaciones habilitan la opción de base de datos Oracle IM para ejecutar queries a una alta velocidad para ejecutar billones de filas por segundo para cada CPU core del servidor. El proceso para crear un ambiente de inteligencia de negocios que anteriormente tomaban horas o días para ejecutarse, con esta opción se completa en Página 7

8 segundos, pudiendo tomar decisiones de negocio en tiempo real como lo habíamos mencionado anteriormente. CONCLUSIÓN Las bases de datos con carga de trabajo mixta ejecutan reportes y queries de la parte de analytics adicionalmente a las transacciones OLTP. Es bastante común crear muchos índices en tablas importantes para agilizar los queries. El formato de columna de base de datos Oracle IM elimina la necesidad de crear la mayoría de los índices, dejando un rendimiento similar a tener un índice en cada columna, pero con la diferencia de que se tiene una sobrecarga menor. Removiendo todos los índices de la parte de analytics, disminuye el tiempo de ejecución de las operaciones transaccionales(oltp), Oracle Real Application Clusters (RAC) puede combinarse con la opción de base de datos IM para aislar cargas de trabajo de OLAP y OLTP, ejecutando cada carga en distintos nodos del cluster. iniciando desde que se eliminan dichos índices. Además, eliminando estos índices, también se elimina el tiempo consumido de operaciones de tuning de queries y mantenimiento requerido para identificar y crear los índices que mejoran el rendimiento de analytics. Más importante, los usuarios ahora pueden facilitar cualquier consulta que necesiten y puedan obtener excelentes tiempos de respuesta. La opción de base de datos Oracle IM no requiere que toda la información de la base de datos se encuentre directamente en memoria. Los usuarios pueden escoger mantener las tablas sensibles al rendimiento o particiones en memoria, mientras que las tablas menos sensibles al rendimiento pueden residir en disco o en memoria flash. Los queries se ejecutan transparentemente al usuario residiendo en las tres capas (memoria, flash y disco) habilitando esta opción, para ser usado en cualquier tamaño de base de datos. Oracle Database In-Memory es completamente compatible con la arquitectura bases de datos Oracle Multitenant, permitiendo bases de datos consolidadas para tomar ventaja de la combinación de manejar rápidamente todo en memoria, así como en tecnologías de almacenamiento de bajo costo. Página 8