Avoiding Block Contention

Block contention occurs when multiple write operations attempt to update the same Oracle Essbase data block simultaneously. Because Essbase applies write locks at the block level, an operation that attempts to access a locked block is queued until the lock is released.

While brief waits may go unnoticed, performance can degrade when block lock partitions are large, particularly when CALCPARALLEL or FIXPARALLEL directives increases the duration or frequency of wait time. To identify why business rules run slow sometimes, but fast at other times, it is critical to capture the specific dates and times (including time zone) when such slow performance occurs. There are two main areas worth investigating:

Use of CALC/FIX PARALLEL to identify all the rules being executed at the time your rule runs slowly. See Use of SET CALCPARALLEL and FIXPARALLEL Calculation Commands.
Block contention across all the calculation passes within the rule being executed at the time your rule runs slowly

Parallel Calculation and Concurrency

The SET CALCPARALLEL or FIXPARALLEL directive determines the number of parallel threads used to execute a business rule. For example, if SET CALCPARALLEL 4 is configured for a rule named myRule, each execution of myRule can request up to four CPU calculation threads. If two users run myRule concurrently, the combined request can be up to 8 calculation threads (4 × 2). Similarly, if eight users run the rule concurrently, the combined request can be up to 32 calculation threads (4 × 8).

When rules run slower than expected, review the Max Number of Calculation Threads value in the Activity Report for the affected date and time. If this value is high, identify the business rules that use CALCPARALLEL and FIXPARALLEL and consider reducing the degree of parallelism or removing parallel execution, particularly for rules that are frequently run concurrently by multiple users.

Block Contention

Block contention is created when two or more write operations simultaneously try to write (place a write-lock) to the same BSO block.

When you input data in a BSO cube or run a business rule to change data, Essbase places a write-lock on the affected blocks. A different block is created for each sparse combination; the dense dimensions form the cells within the block. Unless the contention is pervasive, Essbase handles contention well by introducing wait time for each process so that the write lock is released after each calculation.

When two or more write locks are requested against the same sparse combination, write-lock contention may introduce wait time that may negatively affect performance in the following situations:

A large number of write locks are present
Calculations affect large partitions
Calculation takes a long time to complete

Effect of Parallel Calculations on Block Contention

The use of FIXPARALLEL or CALCPARALLEL in rules can exacerbate block contention when rules run concurrently. Parallel execution may cause a larger portion of the cube to be processed and locked at the same time, increasing both the number and duration of potential write-lock conflicts.

With serial execution, a calculation typically progresses through sparse blocks sequentially, reducing the number of blocks being processed simultaneously. As a result, write-lock wait times between concurrent calculations are often short or negligible and may go unnoticed by users.

For this reason, FIXPARALLEL and CALCPARALLEL are generally not recommended for rules that are expected to run concurrently. Serial execution may provide more consistent performance by reducing the likelihood and severity of block contention.

Using Run-Time Prompts to Avoid Block Contention

To avoid write-block contention, use run-time prompts (RTPs) in forms to capture the specific sparse combination for which each user wants to enter or calculate data. By directing users to different blocks within the cube, RTPs help minimize, and in many cases eliminate, the risk of block contention.

Performance Tuning Objective

When tuning business rules, optimize for the best consistent execution time under the expected level of concurrency, rather than the fastest execution time in a single-user test.

A highly parallel rule may perform well when it runs alone but perform poorly when several users execute it simultaneously because of increased CPU demand and block contention. Testing should therefore reflect realistic concurrent usage, and parallelism should be reduced when serial execution provides more predictable overall performance.