COMMIT BLOCK

English (Español a continuación)

When Essbase performs a transaction (data load or calculation) to send the information from the server’s memory to disk, it can use two different procedures (Isolation Level):

• Committed Access: Essbase maintains the write lock on all blocks affected by the transaction until this is completed; at that point it frees the blocks and sends the data to disk.
• Uncommitted Access: this is the method Essbase applies by default. Essbase releases blocks once they are updated, but does not send it to disk until the transaction is completed or until a certain threshold (called a synchronization point) has been reached.
  • This procedure is more efficient.
  • The parallel calculation only works with «Uncommitted Access».

In this “Uncommitted Access” procedure, Essbase uses two thresholds to determine the synchronization point.

• Committ Block: number of blocks modified before sending them to disk. The default value is 3,000 blocks.
• Commit Row: in data loading processes it is the number of rows loaded before sending them to disk. The default value is 0 (it means that the synchronization occurs at the end of the data load).

If both parameters are informed, synchronization occurs when the first one is reached.

• If the data cache is too small to store the number of blocks specified in the previous two parameters, the block is written to disk as soon as the cache is full, which can occur before the synchronization point is reached.

Essbase performs as many synchronization processes as necessary to finalize the transaction.

Focusing on the “COMMIT BLOCK” parameter, the assigned value can be fine-tuned to gain efficiency:

• It is not the most relevant factor, but it can contribute to significantly improve the level of efficiency.
• If the blocks, once compressed, are very small, the number of 3,000 blocks may be too reduced, generating excessive read / write operations, seriously damaging the level of efficiency.
• Can be set within a range of 3,000 to 100,000 blocks. Right-clicking on the base and selecting Edit / Properties. In the open menu, select «Transactions» in which the number of blocks can be modified (Apply).
• The adjustment should be carried out progressively, testing gradual increments (5,000 / 10,000 / 15,000…) and measuring the response times of the loads / calculations to detect the optimum point.
• It can also be adjusted automatically by Essbase by trying to make read / write operations transfer 10MB of data. This adjustment is reflected in the log.

When the setting exceeds 20,000 blocks, the density of the block must be analyzed.

• A very low density can generate many small blocks, with a negative impact on efficiency (many read / write operations) and can negatively affect the level of fragmentation of the base. In this case, the structure of the dimensions must be analyzed and, if it is posible, modified.
• Normally the density levels are usually low, but below 1% it must be considered especially low.

Another aspect to analyze is the compression ratio:

• If this ratio is too low it means that there is a lot of compression, indicating that there are too many blocks with #Missing. Aspect that must also be analyzed since it generates compressed blocks of very small size.

Español

Cuando Essbase realiza una transacción (carga de datos o cálculo) para enviar la información desde la memoria del servidor al disco puede utilizar dos procedimientos diferentes (Isolation Level):

• Committed Access: Essbase mantiene el bloqueo de escritura sobre todos los bloques afectados por la transacción hasta que ésta ha finalizado; en ese momento libera los bloques y envía los datos al disco.
• Uncommitted Access: es el método que Essbase aplica por defecto. Essbase va liberando los bloques a medida que los va actualizado, pero no envía el bloque al disco hasta que la transacción ha finalizado o hasta que se haya alcanzado un determinado umbral (llamado punto de sincronización).
  • Este procedimiento es más eficiente.
  • El cálculo paralelo tan sólo funciona con “Uncommitted Access”.

En este procedimiento “Uncommitted Access” Essbase utiliza dos umbrales para determinar el punto de sincronización.

• Committ Block: número de bloques modificados antes de enviarlos al disco. El valor por defecto es 3.000 bloques.
• Commit Row: en procesos de carga de datos es el número de filas cargadas antes de enviarlas al disco. El valor por defecto es 0 (significa que la sincronización ocurre al final de la carga de datos).

Si ambos parámetros están informados la sincronización ocurre en el momento en el que se alcanza el primero de ellos.

• Si el data cache es demasiado pequeño para almacenar el número de bloques especificados en los dos parámetros anteriores, el bloque se escribe en el disco tan pronto como la caché está llena, lo que puede ocurrir antes de alcanzar los puntos de sincronización.

Essbase realiza tantos procesos de sincronización como sean necesarios para finalizar la transacción.

Centrándonos en el parámetro “COMMIT BLOCK” el valor asignado se puede afinar para ganar en eficiencia:

• No es el factor más relevante pero si puede contribuir a mejorar sensiblemente el nivel de eficiencia.
• Si los bloques, una vez comprimidos, son de tamaño muy pequeño el número de 3.000 bloques puede resultar reducido, generando excesivas operaciones de lectura / escritura, perjudicando seriamente el nivel de eficiencia.
• Se puede ajustar dentro de un rango entre 3.000 y 100.000 bloques. Haciendo click con el botón derecho sobre la base y seleccionando Editar / Propiedades. En el menú que se abre se selecciona “Transacciones” en el que se puede modificar el número de bloques (Aplicar).
• El ajuste conviene realizarlo progresivamente, probando incrementos paulatinos (5.000 / 10.000 / 15.000…) y midiendo los tiempos de respuestas de las cargas / cálculos para detectar el punto óptimo.
• También Essbase lo puede ajustar de forma automática tratando de que las operaciones de lectura / escritura transfieran 10 MB de datos. Este ajuste queda reflejado en el log.

Cuando el ajuste supera los 20.000 bloques hay que analizar la densidad del bloque.

• Una densidad muy baja puede generar muchos bloques de pequeño tamaño, con un impacto negativo en eficiencia (muchas operaciones de lectura / escritura) y puede afectar negativamente al nivel de fragmentación de la base. En este caso hay que analizar la estructura de las dimensiones por si se puede modificar.
• Normalmente los niveles de densidad suelen ser bajos, pero por debajo del 1% sería especialmente reducido.

Otro aspecto que hay que analizar es el ratio de compresión:

• Si este ratio es muy bajo significa que hay mucha compresión, indicando que hay demasiados bloques con #Missing. Aspecto que también hay que analizar ya que genera bloques comprimidos de tamaño muy reducido.