✒️SAP BI / BW BO Query

Query

1) Bussines Explorer y Usuarios

La mayoría de los usuarios del negocio necesitan una interfaz que sea facíl de usar, y les de el acceso a toda la información que necesitan. Los analistas de la información 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:

1) Los usuarios finales necesitan colecciones de datos predefinidos.

2) Los usuarios finales necesitan predefinir rutas de navegación.

3) Los usuarios finales necesitan poder navegar por sí 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 queries puede tener un impacto significativo en el rendimiento. A veces los queries de larga ejecución son el resultado de un mal diseño, y no es 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 las columnas.

Una característica sólo debe utilizarse en las columnas de determinadas circunstancias (como puede ser una fecha). Características con valores potencialmente grande (como OMATERIAL) 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 que las características libres aparecen a la izquierda del reporte y puede 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 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 de evitar la opción exclusión si es posible, esto se debe a que sólo la inclusión de características puede utilizar indices en las bases 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 Ia 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.2.1.

} Otros consejos para el diseño de queries:

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.

El uso de gráficos puede tener impacto en el rendimiento de los reportes.

AUDIO: Consejos útiles para mejorar los tiempos de ejecución de las consultas, tratar de no armar un query genérico con todas las características y ratios, a veces es recomendable armar Queris precisas con los objetos que necesita el usuario filtrando hasta donde se pueda las características incorporadas, sobre todo cuando el usuario no es analista solo necesita un reporte fijo para su gestión aunque una desventaja de esto es la dependencia del usuario hacia el personal de sistema cuando necesita incorporar un objeto nuevo al reporte, otro tip es crear agregados útiles, es decir hay que realizar un análisis de los distintos tipos de reportes que se ejecutan, de ellos hay que utilizar características y filtros para luego crear de ser necesario el o los agregados que sean convenientes una desventaja de realizar más agregado es que ocupan más espacio físico de almacenamiento y vuelva lenta la carga del InfoCubo.

2) Caché 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 Business 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, puede 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 queries pueden ser mejorados de manera significativa.

Para optimizar el uso de la caché de OLAP existen dos posibilidades para almacenar el conjunto de datos resultado de la consulta: o bien en la memoria principal (distribuidos 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, usted 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 qué 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 caché 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 ptimero a la transacción RSRT, buscar un reporte y allí presionar en el botón "atributos":

} Cache 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 con el 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 memoria caché se utiliza superando los datos admitidos se escribirán en la memoría secundaria (Cluster/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é, los menos usados recientemente (Algoritmo LRU) elimina o intercambia los datos del query.

Para tener una mirada más cercana al LRU en primer lugar debería imaginar que las entradas son ordenados como en la siguiente Imagen 2.4.

La primera entrada de caché está señalada con el llamado Puntero del anillo. Él le dice a la LRU dónde empezar a buscar las entradas que pueden ser removidas o cambiadas. En caso de que el caché se haya agotado, la LRU se moverá en el sentido horario. Si encuentra el valor adecuado, el puntero del anillo se coloca en la Cache-Entrada posterior.

3) Monitor de caché (RSRCACHE)

Las pruebas de seguimiento de consultas, controles y gestion de queries 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 caché (RSRCACHE)

En la pantalla de Cache Monitor es capaz de obtener una visión general, parámetros de la caché, 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 caché 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 de 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.2.9.

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.

} Procesos en paralelo durante la ejecución de un query

Una consulta puede ser dividida en sub-consultas por el sistema. Si dividiendo los resultados de consulta en más de una sub-consulta, 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 utilizan para 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.

EI 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 sub-consultas es mayor que el nivel máximo de paralelismo, todas las sub-consultas existentes se reparten entre los procesos de trabajo determinados por el grado de paralelismo.

Los resultados de todas las sub-consultas se recogen en un punto de sincronización, que fueron determinados para formar un resultado provisorio se transmite inmediatamente al motor OLAP.