Utilización de memoria del O3 Server Caché de cubos

 Idea: aprovechar información del cubo (hechos y dimensiones) que queda en memoria  No es como la redundancia en cuanto a que el resultado se ve en la segunda consulta  Controla qué cubos permanecen abiertos (pero sin conexiones) y cuáles se sacan de la caché si es necesario.  Se utilizan 4 parámetros:  máxima cantidad de cubos en caché (admserver)  tamaño de la caché (en bloques de 4096 bytes)  en gserver.properties: ideasoft.o3.pool.totalMaxCache (en bloques, por defecto 25000)  máx y mín caché del cubo (en bloques, definido en el Designer ó Admserver) ›Valores por defecto MAX=2000, MIN=1000

Estrategia  se mantienen cubos en memoria mientras la suma de las min caché sea inferior al máximo  si no alcanza y hay cubos sin conexiones, entonces éstos se cierran y se recalcula la caché disponible.  si no alcanza y no hay cubos sin conexiones, entonces no se permite abrir el cubo y se da aviso  max caché es utilizado para distribuir la memoria disponible entre los cubos abiertos. El criterio utilizado para esta distribución es que mayor máximo significa más memoria con respecto a los otros cubos abiertos

Abriendo cubos al iniciar el Servidor  Idea: definir qué cubos se abren cuando inicia el servidor  El propósito es que cuando el primer usuario se conecte a cualquiera de esos cubos, el proceso de carga inicial ya fue hecho, por lo cual la consulta inicial es más rápida.  Prioridades: Ninguna…. Muy Alta  Se utilizan en el caso de que la capacidad de caché no sea suficiente

Redundancia  Posibles pasos para optimizar un cubo con redundancia  Optimizar el cubo a nivel de diseño para bajar todo lo posible tiempos construcción (ver recomendaciones básicas diseño)  Construir el cubo solo con redundancia top most  Agregar niveles de redundancia bajos subiendo un nivel en las dimensiones conocidas pesadas (Ej. [1,0,0,0,1,0,0…]) ›saber qué tipos de consultas se hacen ›dimensión fecha es gran candidata siempre (nivel mes o trimestre)  En cada caso comprobar con RedunMgr si hay mejora  Si se necesita mucho tiempo de pruebas entonces hacer un cubo representativo mas pequeño  Una vez que el cubo entra en producción, usar datos estadísticos para analizar tiempos de consultas

Recomendaciones básicas de diseño  Evitar doble recorrida tabla de hechos  no crear dimensiones a partir de tablas de hechos, usar catálogos. (modelo estrella, snowflake)  crear dimensión fecha con un catálogo y no desde la tabla de hechos (dos formas: catálogo con un día por cada año o campo virtual y append)  Almacenamiento optimizado de medidas y dimensiones  utilizar el soporte de datos adecuado, byte, short, int, double  Partir el cubo en varios

Parámetros de redundancia  Momento de la construcción de la redundancia  Al momento de construir el cubo ›Mejor si hay poca agregación a nivel base  Al final ›Se debe levantar todo el cubo

Optimizacion de JBoss  Memoria  Cache de cubos  Apertura de cubos al levantar  Optimización de los cubos: Redundancia  Los cubos deben funcionar bien standalone  Para monitorear performance:  Monitoreo memoria Jboss  Monitoreo de O3Server: sessiones abiertas  Monitoreo de cubos: análisis de cubos de monitoreo -stats -debug