✒️SAP BI / BW BO Query
SAP BI / BW BO Query
Diseño de Queries
Hay una serie de tecnicas de diseño utilizadas por desarrolladores para brindar un rendimiento optimo de consulta.
- Las caracteristicas se colocan en filas y los ratios en columnas (en la mayoria de los casos)
- Solo en determinadas circunstancias utilizar una caracteristica en una columna (por ejemplo, una fecha)
- Caracteristicas con valores potencialmente grandes no deben agregarse a las columnas sin un filtro o variables; alternativamente podria integrarse a la consulta como una caracteristica libre (aparecen a la izquierda del reporte y pueden ser insertadas posteriormente a la ejecucion) para ser utilizada en la navegacion.
- Las caracteristicas de tiempo como el dia, el mes y el año calendario deben ser incluidos entre las caracteristicas libres
- Es necesario utilizar variables para las caracteristicas de tiempo, ya que en la mayoria de los informes un periodo de tiempo actual es util (mes en curso, año calendario anterior o actual)
- El uso de variables y listas desplegables mejora el rendimiento de las consultas haciendo que los datos de la solicitud sean mas especificos
- Al utilizar ratios restringidos, filtros o selecciones, evitar la opcion EXCLUSION (si es posible) ya que solo la inclusion de caracteristicas puede utilizar indices en las bases de datos.
- A realizar consultas a un Multisitio se leeran todos los infoproviders en él. Utilizar la restriccion de la caracteristica virtual 0INFOPROVIDER para leer solo los infoproviders que se necesitan y asi evitar leer muchas bases de datos innecesariamente
- Calculo de celda a traves del editor de celdas genera nuevas cosultas en tiempo de ejecucion (usar cuidadosamente)
- Si utiliza variables de exit verificar correctamente el codigo de estos
- El uso de graficos puede tener impacto en el rendimiento de los reportes.
- No armar un query generico con todas las caracteristicas y ratios, en tal caso armar querys precisas con los objetos necesitados por el usuario (muy utilizado en casos de usuarios no analistas que solo necesitan reportes fijos). Su desventaja se cuando el usuario debe añadir un nuevo objeto al reporting y debe solicitarlo.
- Crear agregados utiles, al analizar los distintos reportes cada uno posee caracteristicas y filtros que seran utilizados para luego realizar distintos agregados. La desventaja de muchos agregados es que ocupan mayor espacio fisico y hacen mas lenta la carga del infocubo.
Cache OLAP
Las esructuras OLAP proporcionan metodos para navegar a traves de los datos en varias diensiones.
Business Explorer pide los datos al infoprovider y presenta la vision actual de los datos almacenados, se transfieren solo los datos de consulta, si se quiere una vista diferente de los datos al navegar, se obtiene desde el infoprovider con el procesador OLAP. La cache OLAP (de datos de consulta) tiene el fin de prever mejores accesos, mejorando el rendimiento de los queries.
Existen dos posibilidades de optimizacion de la cache OLAP para almacenar el conjunto de datos resultado de la consulta: en memoria principal (distribuidos en uno o mas servidores de aplicaciones) o persistente. Para saber cual elegir se debe pensar la frecuencia con que se solicita la consulta ya que el resultado de las consultas de datos que se solicitan con frecuencia se almacenara en la cache. Tambien tomar en cuenta la complejidad de la consulta, en caso de obtener un resultado complejo éste será procesado por el procesador OLAP y almacenado en la cache. Tambien tomar en cuenta l frecuencia con que se cargan los datos ya que si los datos en las consultas suelen modificarse teniendo que ser cargado con frecuencia, el almacenamiento en cache no es ventajoso pues la cache debe generarse cada vez.
Con la transaccion RSCUSTV14 se puede cambiar el modo de amacenamiento en cache.
Modos de Cache
Determinan si (y de que manera) los resultados de consulta y estados de navegacion se van a guardar en la cache de OLAP.
- Cache inactivo
- Memoria principal cache sin Swapping (intercambio): los datos almacenados en la cache se almacenan en la memoria principal, al agotarse la memoria los datos son retirados
- Memoria principal cache con swapping: Idem antrior, solo que esta vez si la memoria cache se agotara, sus datos se escribiran en una memoria secundaria (cluster/archivo plano) y se podra volver a cargar la cache OLAP al ejecutar una nueva solicitud
- Cluster/Archivo plano, Cache por servidor de aplicacion: los datos almacenados en cache se almacenan persistentemente en forma de tablas o en una base de datos o como un archivo en un directorio del servidor de aplicaciones (como recomendacion, elegir un drectorio proximo al servidor de aplicaciones)
- Cluster/Archivo plano, Cache valido para todos los servidores de aplicacion: los datos almacenados en cache se almacenan persistentemente como un cluster 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
Se utiliza cuando hay datos pendientes de ser almacenados en la cache pero esta esta agotada, este algoritmo busca los datos menos usados recientemente (LRU) y los elimina o intercambia. La primera entrada de cache esta firmada con el llamado Anillo de puntero, este le indica a la LRU donde empezar a buscar las entrada que pueden ser removidas o cambiadas. Al agotarse la cache, la LRU se mueve en sentido horario y al encontrar un valor adecuado, ubica el puntero del Anillo en la cache-entrada posterior.
Monitor de Queries (RSRT)
Nos permite realizar pruebas de seguimiento de consultas de queries asi como el control y gestion de las mismas. Se puede probar queries, chequearlas o cambiar sus propiedades. Tambien podemos entrar al monitor de cache.
Monitor de Cache (RSRCACHE)
Obtendremos una vision general de la cache, sus parametros, la cantidad de memoria utilizada por los objetos en tiempo de ejecucion de consultas y la estructura actual de cache subyacente.
La cache OLAP se crea jerarquicamente y su arbol de directorios de divide en cuatro niveles.
Con cada consulta ejecutada un directorio propio sera creado y su nombre se determina por el nombre tecnico del infoprovider y el query. Haciendo doble click sobre las entradas se vera la info sobre las jerarquias o variables usadas en la consulta.
Brinda info tecnica que permite una vision general del tamaño de cache maximo y las entradas reservadas actualmente en la cache para el objeto en tiempo de ejecucion.
El sistema puede dividir una consulta en varias subconsultas, se realiza la operacion de lectura en forma paralela permitiendo mayor rapidez. El grado maximo de paralelismo determina el numero maximo de procesos que se utilizan para cada consulta, por defecto esta limitado a 6 pero puede variar de 1 a 100 mediante la entrada QUERY_MAX_WP_DIAG dentro de la tabla RSADMIN.
Si el numero de subconsultas es mayor que el nivel maximo 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 sincronizacion que fue determinado para formar un resultado global.
En el tratamiento secuencial (numero de parlelismos igual a 1) las subconsultas se procesan una tras otra y el resultado provisorio se transmite inmediatamente al motor OLAP.
 
 
 
Sobre el autor
Publicación académica de Milton Ezequiel Bravo, en su ámbito de estudios para la Carrera Consultor en SAP BI / BW BO.
Milton Ezequiel Bravo
Profesión: Project Manager en Newbitcrew - Argentina - Legajo: HQ58N
✒️Autor de: 50 Publicaciones Académicas
🎓Egresado de los módulos:
Disponibilidad Laboral: FullTime
Certificación Académica de Milton Bravo