✒️SAP BI / Query Por Gerson Pozo Contreras

Performance en los querys

1. Business Explorer y Usuarios

La mayoría de los usuarios del negocio necesitan una interfaz que sea fácil de usar, y les de el acceso a toda la información que necesitan. Los analistas son los usuarios que requieren muchas más funciones de análisis.

El objetivo principal de los modeladores debe ser un buen apoyo a los usuarios finales de la información:

· Los usuarios finales necesitan colecciones de datos predefinidos.

· Los usuarios finales necesitan predefinir rutas de navegación.

· Los usuario finales necesitan para navegar por si mismo para analizar la información.

Los desarrolladores crean consultas en función de los roles de los usuarios finales y analistas.

Los analistas trabajan con informes, lo analizan, y realizan un reordenamiento de los datos para descubrir información importante.

Diseño de un query para un óptimo desempeño

El diseño de querys puede tener un impacto significativo en el rendimiento. A veces los querys de larga ejecución son el resultado de un mal diseño, y no sólo por la cantidad de los datos. Hay una serie de técnicas de diseño que los desarrolladores pueden utilizar para proporcionar un rendimiento óptimo de consulta.

Por ejemplo, en la mayoría de los casos las características se deben colocar en las filas y los ratios en columnas

Una característica sólo debe utilizarse en las columnas de determinadas circunstancias (como puede ser una fecha).

Características con valores potencialmente grandes (como 0material) no debe ser agregado a las columnas sin un filtro o variables. Alternativamente, se puede integrar en la consulta como una característica libre para que pueda ser utilizado en la navegación.

RECUERDE: Las características libres aparecen a la izquierda del reporte y pueden ser insertadas posteriormente en la ejecución.

Si una característica de tiempo relativamente detallada, como puede ser el día (0CALDAY), las características de tiempo más agregada como el mes (0CALMONTH), y el año calendario (0CALYEAR) también deben ser incluidos entre las características libres.

Para la mayoría de los informes, un período de tiempo actual (Mes en curso, año calendario anterior o actual) es útil. Por esta razón, el uso de variables es particularmente necesario para las características de tiempo.

Las variables y las listas desplegables puede mejorar el rendimiento de las consultas, haciendo que los datos de la solicitud sea más específica.

Cuando se utilizan ratios restringidos, filtros o selecciones, trate d evitar la opción exclusión si es posible, esto se debe a que sólo la inclusión de características puede utilizar índices en la base de datos.

Cuando una consulta se ejecuta en un Multisitio todos los InfoProviders en ese MultiSitio son leídos. La selección de los InfoProviders en un query a un Multisitio se puede controlar mediante la restricción de la característica virtual 0INFOPROV para leer sólo la InfoProviders que se necesitan. De esta manera, no habrá base de datos leídas innecesariamente. Esto lo podemos ver en la imagen 1.3

OTRO CONSEJOS PARA EL DISEÑO DE QUERYS

Cálculo de la celda a través del editor de celdas genera nuevas consultas en tiempo de ejecución. Use cuidadosamente este tipo de cálculos.

En caso que utilice variables de exit, verifique correctamente el código de estos.

NOTA: Exits de Cliente y el uso de celdas será visto en la unidad 3.

“El uso de gráficos puede tener impacto enel rendimiento de los reportes”

TIP: Al armar un query conviene tratar de no armar un query genérico con todas las características incluidas, a veces es necesario armar querys precisas con los objetos que necesita el usuario filtrando las características hasta donde se pueda, sobre todo cuando el usuario necesita un reporte fijo para su gestión, aunque exista una desventaja y es la dependencia del usuario para cuando necesite incorporar un objeto nuevo al reporte, otro tip es la inclusión de agregados útiles, para ello hay que realizar un análisis de los diferentes reportes que se utilizan y entender que características y filtros se utilizan y así luego crear los agregados necesarios.

2. Cache OLAP

Los datos de BI se analizan mediante la definición de queries a InfoProviders. Estos son definidos por selección de características y cifras clave.

Debido a la naturaleza multidimensional de los datos del query, puede crear diferentes puntos de vista de un conjunto de datos. Las estructuras OLAP proporcionan métodos para navegar a través de los datos en varias dimensiones.

El Bussiness Explorer pide los datos del InfoProvider y presenta la visión actual de los datos almacenados. Sólo los datos de consulta que se requieren son transferidos. Si quiere una vista diferente de los datos cuando se navega, puedo obtenerlo desde el InfoProvider con el procesador OLAP.

El caché de datos de consulta OLAP buffers tiene el fin de prever mejores accesos. De esta manera el rendimiento de los querys pueden ser mejorados de manera significativa.

Para optimizar el uso de la caché de OLAP existen 2 posibilidades para almacenar el conjunto de datos resultado de la consulta o bien en la memoria principal (distribuido en uno o más servidores de aplicaciones) o persistente.

La opción que elija dependerá de las siguientes preguntas:

· ¿Con qué frecuencia se solicita la consulta? El resultado de las consultas de datos que se solicitan con frecuencia se almacenará en la caché.

· ¿Cuán compleja es la consulta? Si el resultado es complejo, será procesado por el procesador OLAP y se almacenará en la caché.

· ¿Con qué frecuencia se cargan los datos? Si los datos en consultas suele modificarse y por lo tanto tiene que ser cargado con frecuencia, el almacenamiento en caché es apenas ventajoso, ya que la caché tiene que generarse cada vez.

Si la caché no se desea, ud tiene la posibilidad de cambiar el modo de almacenamiento en caché a través de la personalización mediante la transacción RSCUSTV14.

MODOS DE CACHÉ

El modo de caché determina si y de que manera los resultados de consulta y estados de navegación (calculado por el procesador OLAP como datos de alta compresión) se van a guardar en la caché de OLAP.

A fin de lograr un uso ideal de la cache de OLAP, se encuentran los siguientes modos que podemos observar en la imagen 2.3. Para acceder a las propiedades de caché de un reporte debemos acceder primero a la transacción RSRT, buscar un reporte y allí presionar el botón “atributos”.

CACHÉ Is Inactive(0)

El almacenamiento en caché cruzada transaccional está desactivado. Esto significa que ningún resultado de datos se llevará a cabo en la memoria caché.

Memoria Principal cache sin Swapping(1)

Los datos almacenados en caché se almacenan en la memoria principal. En el caso de que la memoria se agota, los datos se retirarán de acuerdo al algoritmo LRU como veremos más adelante.

Memoria Principal cache con Swapping(2)

Los datos almacenados en caché se almacenan también en la memoria principal. Si la caché se utiliza superando los datos admitidos se escribirán en la memoria secundaria (Clúster / Archivo plano) y podría volver a cargar en la caché de OLAP al ejecutar una nueva solicitud.

Cluster / Archivo plano, cache por Application Server

Los datos almacenados en caché se almacena persistentemente en forma de tablas o en una base de datos o como un archivo en un directorio del servidor de aplicaciones. En general se recomienda elegir un directorio que esté próximo al servidor de aplicaciones.

Cross- Application Server cache Cluster/Archivo plano cache

Los datos almacenados en caché se almacenan persistentemente como un clúster de servidores de aplicaciones cruzadas, tabla o un archivo en un sistema de archivos en la red, accesible desde todos los servidores de aplicaciones.

Algoritmo LRU

Si la caché de la memoria principal se agota, pero más datos tienen que ser escritos en la memoria caché, elimina los menos usados recientemente (Algoritmo LRU) o intercambia los datos del query.

El LRU se mueve sentido Horario

3. MONITOR DE QUERYS (rsrt)

Las pruebas de seguimiento de consultas, controles y gestión de queris BI se realizan mediante el uso del monitor de queries. Puede probar un query, así como el chequeo o cambio de propiedades.

Con esta pantalla nos permite también la entrada en el monitor de la caché.

Monitor de la cache (RSRCACHE)

En la pantalla de Cache Monitor es capaz de obtener una visión general, parámetros de la cache, la cantidad de memoria utilizada por los objetos en tiempo de ejecución de consultas y la estructura actual de caché subyacente.

La pantalla de inicio del monitor de cache muestra los diferentes parámetros, establecidos para la caché de OLAP.

En un punto de vista lógico la cache de OLAP se crea jerárquicamente y por lo tanto es igual a la presentación jerárquica de los objetos.

El árbol de directorios de la caché OLAP se divide en cuatro niveles.

Por cada consulta ejecutada será un propio directorio creado. El nombre de este directorio es determinado por el nombre técnico del InfoProvider y el query.

Las entradas de estos directorios contienen los datos del resultado real de las diferentes consultas.

Mediante un doble clic sobre una entrada aparece un diálogo que muestra información acerca de jerarquías o variables incluidas en la consulta.

Al igual que en el punto de vista histórico puede obtener información detallada acerca de las jerarquías y variables como vemos en la imagen 3.3.

La información técnica da una visión general del tamaño de caché máximo y las entradas reservadas actualmente en la caché para el objeto en tiempo de ejecución.

Proceso en paralelo durante la ejecución de un query.

Una consulta puede ser dividida en subconsultas por el sistema. Si dividiendo los resultados de consulta en más de una subconsulta, la operación de lectura se realiza en paralelo de forma predeterminada esta será mucho más rápida.

El grado máximo de paralelismo determina el número máximo de procesos que se usan en cada consulta. Este valor está limitado a 6 por defecto. El valor máximo se puede cambiar a un valor entre 1 y 100 en la entrada QUERY_MAX_WP_DIAG dentro de la tabla RSADMIN.

El grado real en que las consultas se ejecutan en paralelo depende de la carga en el sistema en un momento dado y se encuentra entre 1 (procesamiento secuencial) y el valor máximo. Si el número de subconsultas es mayor que el nivel máximo de paralelismo, todas las subconsultas existentes se reparten entre los procesos de trabajo determinados por el grado de paralelismo.

Los resultados de todas las subconsultas se recogen en un punto de sincronización que fueron determinados para formar un resultado global. En el tratamiento secuencial, las subconsultas se procesan uno tras otro. El resultado provisorio se transmite inmediatamente al motor OLAP.