Como plataforma de “Business Intelligence” y “Analytics”, Oracle OBIEE Server se conecta a una base de datos física la cual puede ser una “Oracle Database” a través de ODBC/JDBC , presentando un esquema de vista lógica independiente de la base de datos física. Cuando un usuario ejecuta los reportes, el OBIEE server traduce o mapea los SQL lógicos desde la capa de presentación del reporte a consultas físicas SQL, enviando estos SQL a la base de datos, de esta manera Oracle database ejecuta las consultas SQL físicas, obteniendo los datos correspondientes y retornándolos al OBIEE server para armar el reporte. La herramienta de administración de Oracle BI muestra estas tres capas: Presentación(Presentation), Modelo de negocio y mapeo ( Business Model and Mapping), y Física (Physical).
Figura 3: Herramienta de Administración de Oracle BI
Nosotros estamos usando el siguiente ejemplo para discutir cómo usar la opción Oracle In-Memory puede acelerar reportes de Oracle BI.
Nosotros estamos usando el siguiente ejemplo para discutir cómo usar la opción Oracle In-Memory puede acelerar reportes de Oracle BI.
Por lo general, el procesamiento de BI analytics demanda una gran cantidad de datos a la base de datos. En el nivel físico de BI report, es posible que se puedan ver muchos “full table scan”a tablas muy grandes y complejas operaciones de unión sobre estas inmensas tablas. Principalmente las operaciones de E/S para estos grandes “full table scan” ocupan una gran parte del tiempo de la ejecución de los reportes. Una reducción de estas operaciones de E/S puede mejorar significativamente el rendimiento de los informes. Con la opción de Oracle In-Memory, podemos cargar de manera parcial o en su totalidad esas tablas sobre las cuales se realiza “full table scan”en Oracle In-Memory Store. Con estas tablas en la memoria de base de datos, podemos reducir significativamente el tiempo físico de la consulta SQL.
Partiendo de estas ideas, podemos aplicar el siguiente proceso:
- Iniciar con el reporte que presenta lentitud y encontrar la capa de presentación del mismo.
- Por medio del mapeo desde la capa de presentación a la capa física, identificar el SQL físico utilizado en el reporte.
- Por medio del SQL físico identificar las operaciones de “full table scan” que ocurren por debajo.
- Sumar algunas de la tablas subyacentes al In-Memory column store.
En el resto del artículo utilizaremos un ejemplo para poder recorrer este proceso:
1- Identificar la capa física de SQL correspondiente al reporte:
Con un reporte particular para ajustar su rendimiento, podemos echar un vistazo al mapeo desde el reporte a la capa física. Por ejemplo tomamos un reporte llamado EDI Queue el cual demora más de 9 minutos y medio en correr. Nos gustaría acortar el tiempo de ejecución del mismo con la funcionalidad objeto de este articulo “Oracle In-Memory”.
Por medio de la capa de presentación encontrar el “Business Model” y “mapping” de “Fact EDI QUEUE”, hemos identificado la vista física de base de datos FACT_EDI_QUEUE_V, la cual representa el “SQL Statement” para este reporte tal como lo podemos ver abajo:
Figura 4: Las tres capas y su mapeo
No hay comentarios:
Publicar un comentario