DATA CACHE

Essbase keeps data in blocks (data blocks) stored in «Data Files».

The block is made up of cells:

• There is a cell for each possible combination of the members of the dense dimensions.
• There is a block for each possible combination of the members of the sparse dimensions in which there is at least one piece of data in a cell.

The block size is calculated by multiplying the number of cells in a block by the size of each cell (8 bytes):

• Number of cells in a block is equal to the product of the number of members of dense dimensions (excluding: attribute dimension members, shared members, “labels only” members, “dynamic calculation” members).

Let’s see an example: Let’s suppose a database with the following dense dimensions:

• Markets: 12 members
• Sellers: 20 members
• Products: 33 members

The number of cells in the block:

• Number of cells = 12 * 20 * 33 = 7,920 cells

• Size (uncompressed) = 7,920 * 8 bytes = 63,360 bytes

But if the database uses a compression system (by default it uses «bitmap encoding» compression) the size of the compressed block could be roughly estimated:

• Block size (compressed) = Block size (uncompressed) * block density
• The density of the block can be consulted in «Database properties» / «Statistics».

For example, if in the previous case the average density of the block is 3%, the size of the compressed block would be:

• Block size (compressed) = Block size (uncompressed) * % density = 63,360 bytes * 0.03 = 1,901 bytes

The «Data Files» files are named «essxxxxx.pag» and are sequential:

• «ess00001.pag»
• «ess00002.pag»
• «ess00003.pag»
• …

Each file has a maximum size of 2.00 GB; when that size is reached the next file is generated.

The size of all the «Data Files» in the database can be consulted in «Database properties» / «Storage».

In an approximate way it could be calculated taking into account the following parameters that can be consulted in «Database properties» / «Statistics»:

(considering that the «Bitmap encoding» compression method is used):

• Number of existing blocks.
• Size of the uncompressed blocks.
• % density of the blocks increased by a % (1/64).
• In addition, all blocks have an additional structural size of 72 bytes.

The formula to apply would be (bytes):

• Size = Number of existing blocks * [expanded block size * (block density + 1/64) + 72]

For example: If in the previous example we assume that the database currently has 22,000 blocks:

• Size = 22,000 * [63,360 * (0.03 + 1/64) + 72] = 65,181,600 bytes

2.- Data cache

Essbase stores the data blocks in the disk and also stores part of them in the “Data Cache” (depending on the size of the cache).

The «Data Cache» is a buffer in memory that stores uncompressed «Data Blocks». It intervenes in charges, in calculations and in consultations.

• Stores the «Data Blocks» that have recently been consulted more frequently.

If a block is required (in a query or in a calculation) Essbase starts by looking for it in the “Data Cache” and if it finds it, it accesses it immediately; If it cannot find it, it searches the Index for the block number and uses that reference to go to the disk and locate it (this process is slower than if it is located in the “Data Cache”).

Cache size

This cache needs to store a limited % of the data in the database.

• Minimum size: 3,072 KB
• Default size: 3,072 KB
• Recommended theoretical size: 0.125 of the sum of the size of all the “essxxxx.pag” files. This size should be increased if:
  • There are usually many simultaneous queries to the database (which can query different blocks of information).
  • Calculation on wide ranges, and functions that require consulting wide ranges of data blocks (@RANK, @ RANGE …).
  • Simultaneous calculations usually coincide.

  According to some analysts, this way of calculating the optimal size of the “Data Cache” presents a problem: the data block is compressed in the “essxxxx.pag” files while in the “Data Cache” it is un compressed: the size ratio between a compressed and a uncompressed block varies from one database to another, and from one moment to the next (as the database is loaded).

  • If it is considered optimal that the size of the “Data Cache” should hold a certain proportion of the blocks of the database, its calculation should start from the size of the uncompressed block and the number of existing blocks.

  In any case, you have to check the hit ratio of the «Data Cache» to see how optimally the cache is working.

  If the size of the “Data Cache” is not enough for the operation that Essbase performs, it will warn with the message “Data Cache is full; Please increase the Data Cache of the database ”. If after successive increases the message continues to appear, it would be necessary to analyze whether it is a problem of the structure of the base (number of blocks, size of the blocks …), or of the calculation, which requires a restructuring.

  Cache statistics

  The «Data Cache» hit rate means Essbase’s success rate in locating the blocks in the «Data Cache» without having to retrieve the block from disk.

  • It can be consulted in «Database properties» / «Statistics».

  This hit ratio should be as high as possible: a ratio of 25% -35% can be considered acceptable.

  Español

  1.- Tamaño de los datos

  Essbase guarda los datos en bloques (data blocks) almacenados en archivos “Data Files”.

  El bloque está formado por celdas:

  • Hay una celda para cada combinación posible de los miembros de las dimensiones densas.
  • Hay un bloque por cada combinación posible de los miembros de las dimensiones dispersas en la que exista al menos un dato en una celda.

  El tamaño del bloque se calcula multiplicando el número de celdas que tiene un bloque por el tamaño de cada celda (8 bytes):

  • Número de celdas que tiene un bloque es igual al producto del número de miembros de las dimensiones densas (excluyendo: miembros de dimensiones atributos, miembros compartidos, miembros “solo etiquetas”, miembros “cálculo dinámico”).

  Veamos un ejemplo: Supongamos una base de datos con las siguientes dimensiones densas:

  • Mercados: 12 miembros
  • Vendedores: 20 miembros
  • Productos: 33 miembros

  El número de celdas que tiene un bloque sería:

  • Nº de celdas = 12 * 20 * 33 = 7.920 celdas

  Tamaño del bloque:

  • Tamaño (sin comprimir) = 7.920 * 8 bytes = 63.360 bytes

  Pero si la base de datos utiliza un sistema de compresión (por defecto utiliza la compresión “codificación de mapa de bits”) se podría estimar de forma aproximada el tamaño del bloque comprimido:

  • Tamaño del bloque (comprimido) = Tamaño del bloque (sin comprimir) * densidad del bloque
  • La densidad del bloque se puede consultar en “Propiedades de la base de datos“ / “Estadísticas”.

  Por ejemplo, si en el caso anterior la densidad media del bloque es del 3%, el tamaño del bloque comprimido sería:

  • Tamaño del bloque (comprimido) = Tamaño del bloque (sin comprimir) * % densidad = 63.360 bytes * 0,03 = 1.901 bytes

  Los archivos “Data Files” están nombrados como “essxxxxx.pag” y son secuenciales:

  • “ess00001.pag”
  • “ess00002.pag”
  • “ess00003.pag”
  • …

  Cada archivo tiene un tamaño máximo de 2,00 GB; cuando se alcanza ese tamaño se genera el siguiente archivo.

  El tamaño de todos los “Data Files” de la base de datos se puede consultar en “Propiedades de la base de datos“ / “Almacenamiento”.

  De forma aproximada se podría calcular teniendo en cuenta los siguientes parámetros que se pueden consultar en “Propiedades de la base de datos” / “Estadísticas”:

  (considerando que se utiliza el método de compresión “Codificación de mapa de bits”):

  • Número de bloques existentes.
  • Tamaño de los bloques descomprimidos.
  • % densidad de los bloques incrementado en un % (1/64).
  • Además, todos los bloques tienen un tamaño estructural adicional de 72 bytes.

  La fórmula a aplicar sería (bytes):

  • Tamaño = Nº de bloques existentes * [tamaño expandido del bloque * (densidad del bloque + 1/64) + 72]

  Por ejemplo: Si en el ejemplo anterior suponemos que la base de datos tiene actualmente 22.000 bloques:

  • Tamaño = 22.000 * [63.360 * (0,03 + 1/64) + 72] = 65.181.600 bytes

  2.- Data cache

  Essbase guarda los bloques de datos en el disco y, una parte de ellos, también los guarda en el “Data Cache” (dependiendo del tamaño del caché).

  El “Data Cache” es un buffer en la memoria que guarda “Data Blocks” descomprimidos. Interviene en cargas, en cálculos y en consultas.

  • Guarda los datos de los bloques que recientemente se han consultado con más frecuencia.

  Si un bloque es requerido (en una consulta o en un cálculo) Essbase comienza por buscarlo en el “Data Cache” y si lo encuentra accede inmediatamente; si no lo encuentra, busca en el Índex por el número del bloque y utiliza esa referencia para ir al disco y localizarlo (ese proceso es más lento que si lo localiza en el “Data Cache”).

  3.- Tamaño del cache

  Este caché necesita almacenar un % limitado de los datos de la base de datos.

  • Tamaño mínimo: 3.072 KB
  • Tamaño por defecto: 3.072 KB
  • Tamaño teórico recomendado: 0,125 de la suma del tamaño de todos los ficheros “essxxxx.pag”. Este tamaño se debe incrementar si:
    • Suele haber muchas consultas simultáneas a la base de datos (que pueden consultar diferentes bloques de información).
    • Cálculo sobre rangos amplios, y funciones que requieren consultar rangos amplios de bloques de datos (@RANK, @RANGE…).
    • Suelen coincidir cálculos simultáneos.

    Según algunos analistas esta forma de calcular el tamaño óptimo del “Data Cache” presenta un problema: el bloque de datos se encuentra en los ficheros “essxxxx.pag” comprimidos mientras que en el “Data Cache” está descomprimido: la relación de tamaño entre un bloque comprimido y uno descomprimido varía de una base a otra, y de un momento a otro (según se va cargando la base).

    • Si se considera óptimo que el tamaño del “Data Cache” sea suficiente para albergar una proporción determinada de los bloques de la base de datos, para su cálculo habría que partir del tamaño del bloque descomprimido y del número real de bloques.

    En todo caso hay que consultar el hit ratio del “Data Cache” para ver cómo de óptimo está funcionando la caché.

    Si el tamaño del “Data Cache” no es suficiente para la operación que realiza Essbase, este avisa con el mensaje “Data Cache está lleno; por favor incrementa el Data Cache de la base de datos”. Si tras sucesivos incrementos continúa apareciendo el mensaje habría que analizar si es un problema de la estructura de la base (número de bloques, tamaño de los bloques…), o del cálculo, que exija una reestructuración.

    Estadísticas del caché:

    El hit ratio del “Data Cache” significa el ratio de éxito de Essbase en localizar los bloques en el “Data Cache” sin tener que recuperar el bloque del disco.

    • Se puede consultar en “Propiedades de la base de datos” / “Estadísticas”.

    Este hit ratio debería ser lo más alto posible: un ratio del 25%-35% se puede considerar aceptable.