✒️SAP BI / BW BO Query
SAP BI / BW BO Query
BUSINESS EXPLORER Y USUARIOS
En general los usuarios de negocio requieren acceso a la información con interfaces fáciles de usar. Los analistas de la información son usuarios que requieren más Funciones de análisis.
Los modeladores deben apoyar a los usuarios finales con los siguientes objetivos:
· Los usuarios finales necesitan de datos predefinidos.
· También necesitan de rutas de navegación predefinidas.
· Necesitan navegar por si mismos para analizar la información.
Los desarrolladores crean Querys en función de los roles de los usuarios finales y analistas.
DISEÑO DE UN QUERY PARA UN ÓPTIMO DESEMPEÑO
Existen una serie de técnicas de diseño de querys que los desarrolladores pueden utilizar para proporcionar un rendimiento optimo de consulta. Por ejemplo la mayoría de casos las características deben colocarse en las filas y los ratios en las columnas.
Si se usan características como columnas es aconsejable poner filtros o variables si tienen valores elevados, como por ejemplo la característica Material.
Alternativamente se puede integrar en la consulta como una característica libre para que pueda ser utilizado en la navegación. Las características libres aparecen a la izquierda del reporte y pueden ser insertadas posteriormente en la ejecución.
Se pueden incluir entre las características libres, características de tiempo relativamente detalladas como puede ser el Día (OCALDAY), características de tiempo mas agregada como el Mes (OCALMONTH) y el año calendario (OCALYEAR).
En la mayoría de informes un periodo de tiempo actual o anterior siempre es útil. Se recomienda el uso de Variables para las características de tiempo.
Las variables y las listas desplegables pueden mejorar el rendimiento de las consultas ya que hace que los datos de la solicitud sean más específicos.
Cuando se usen ratios restringidos, filtros o selecciones, hay que evitar en lo posible la opción de exclusión. Esto es porque la inclusión de características permite usar índices en las bases de datos.
Cuando una Query se ejecuta en un MultiSitio, todos los Infositios que utiliza, son leídos. Mediante la restricción de la característica virtual OINFOPROVIDER sólo se leerán los InfoSitios que se necesitan. Con esto ahorramos lecturas innecesarias a la base de datos.
El cálculo de la celda a través del editor de celdas genera nuevas consultas en tiempo de ejecución, con lo que hay que ver si realmente es necesario.
Si se utilizan variables Exit hay que verificar correctamente el código de éstos.
El uso de gráficos también puede tener impacto en el rendimiento de los reportes.
CACHE OLAP
Los datos de BI se analizan mediante la definición de Querys a InfoProviders. Estos son definidos por selección de características y cifras clave.
Las estructuras OLAP proporcionan métodos para navegar a través de los datos en varias dimensiones. Se pueden crear diferentes puntos de vista de un conjunto de datos dada la naturaleza multidimensional de los datos del Query.
Business Explorer pide los datos del InfoProvider y presenta la visión actual de los datos almacenados. Solo se transfieren los datos de consulta que se requieren. Si se quiere una vista diferente de los datos cuando se navega, pueden obtenerse desde el InfoSitio con el procesador OLAP.
El cache de datos de consulta OLAP buffers tiene el fin de prever mejores accesos con lo que pueden mejorar el rendimiento de la Query.
Existen dos opciones para optimizar el uso de la caché de OLAP para almacenar el conjunto de datos resultado de la consulta: En la memoria principal (distribuidos en uno o más servidores de aplicaciones) o persistente.
Si se solicita la consulta de datos frecuentemente, el resultado de la consulta se almacena en la caché.
Si la consulta es compleja se procesará con el procesador OLAP y se almacenara en la caché
Si los datos suelen modificar y por lo tanto tienen que cargarse con frecuencia, el almacenamiento en la caché no es ventajoso, ya que la cache tiene que generarse cada vez. Se puede dejar de usar la cache cambiando el modo de almacenamiento en caché a través de la transacción RSCUSTV14.
MODOS DE CACHÉ
Caché es un conjunto de datos duplicados de otros originales, con la propiedad de que los datos originales son costosos de acceder en tiempo respecto a la copia en el cache. Cuando se accede por primera vez a un dato, se hace una copia en la caché y los siguientes accesos se toman de la caché, mejorando el tiempo de acceso.
El modo de caché determina sí y de qué forma los resultados de la 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.
Tenemos los siguientes modos de cache para lograr un uso ideal de la cache de OLAP:
0 - Cache inactivo
Se desactiva con esta opción el almacenamiento en caché.
1 – Memoria principal caché sin intercambio (swapping)
Los datos almacenados en caché se almacenan en la memoria principal. En el caso, de de que la memoria se agote, los datos se retirarán con el Algoritmo LRU.
2 – Memoria principal caché con intercambio (swapping)
Los datos almacenados en caché se almacenan también en la memoria principal. Si la memoria caché se utiliza superando los límites admitidos, se escribirán en la memoria secundaria (Cluster/Archivo Plano) y podría volver a cargar en la cache de OLAP al ejecutar una nueva solicitud.
Cluster / Archivo Plano, Caché con Application Server
Los datos almacenados en caché se almacenan persistentemente en forma de tablas o en una base de datos o como un archivo en un directorio del servidor de aplicaciones. Es recomendable usar un directorio próximo al servidor de aplicaciones.
Cross-Application Server Cache Cluster /Archivo Plano Cache
Los datos almacenados en caché se almacenan persistentemente como un cluster de servidores de aplicaciones, tabla o un archivo en un sistema de archivos en la red, accesible desde todos los servidores de aplicaciones.
ALGORITMO LRU
Cuando se agota la cache de la memoria principal, y más datos tienen que ser escritos en la memoria cache, los datos menos usados recientemente (Algoritmo LRU) elimina o intercambia los datos del Query.
La primera entrada de cache está firmada con el llamado Anillo de puntero. Él le dice a la LRU donde empezar a buscar las entradas que pueden ser borradas o cambiadas. En caso de que el cache 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.
MONITOR DE QUERYS (RSRT)
Las pruebas de seguimiento de consultas, controles y gestión de querys BI se realizan mediante el uso del monitor de querys. Puede probar un Query, asi como el chequeo o cambio de propiedades. Desde aquí también nos permite la entrada en el monitor de la caché.
Monitor de Caché (RSRCACHE)
En esta pantalla de monitor de cache tenemos una visión general, como los parámetros de la cache, la cantidad de memoria usada por los objetos en tiempo de ejecución de consultas y la estructura actual del cache subyacente.
La pantalla de inicio del monitor de cache muestra los diferentes parámetros establecidos para la cache 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 cache de OLAP se divide en 4 niveles.
Por cada consulta ejecutada se crea un directorio propio. Su nombre se determina 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 dialogo que muestra información acerca de jerarquías o variables incluidas en la consulta.
Al igual que en el punto de vista histórico se puede obtener información detallada acerca de las jerarquías y variables.
La información técnica da una visión general del tamaño de caché máximo y las entradas reservadas actualmente en la cache para el objeto en tiempo de ejecución.
Procesos en paralelo en la ejecución de un Query
Una consulta se puede dividir 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 ésta 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. Por defecto está limitado a 6 pero su valor se puede cambiar entre un valor 1 a 100, en la entrada QUERY_MAX_WP_DIAG dentro de la tabla RSADMIN.
El grado real en el que las consultas se ejecutan en paralelo depende de la carga en el sistema y varía entre 1 (procesamiento secuencial) y el valor máximo. Si el numero de sub-consultas supera el nivel máximo del paralelismo, todas las sub-consultas existentes se reparten entre los procesos de trabajo determinados por el grado de paralelismo.
El resultado de todas las sub-consultas se recogen en un punto de sincronización, que fueron determinados para formar un resultado global. En el tratamiento secuencial, las sub-consultas se procesan uno tras otro. Es resultado provisional se transmite inmediatamente al motor OLAP.
 
 
 
Sobre el autor
Publicación académica de Joaquin Vivas, en su ámbito de estudios para la Carrera Consultor en SAP BI / BW BO.
Joaquin Vivas
Profesión: Administrador de Sistemas y Analista Bi - España - Legajo: PZ32O
✒️Autor de: 87 Publicaciones Académicas
🎓Egresado de los módulos:
Certificación Académica de Joaquin Vivas