Parallel calculation in Oracle Essbase BSO is the capability for the Essbase calculation engine to divide a calculation into independent segments and process those segments simultaneously across multiple CPU threads on the server. When a business rule is executed with parallel calculation enabled, Essbase analyses the calculation’s block dependency graph — determining which blocks can be calculated independently of each other — and distributes the independent segments across the available CPU threads. The result is that a calculation that would take 60 minutes on a single CPU thread may complete in 15-20 minutes when distributed across four threads. Parallel calculation is controlled through the SET CALCTASKDIMS and SET CALCPARALLEL settings in Essbase configuration or within individual Calc Script business rules, and its effectiveness depends on the calculation’s structure, the block dependency graph, and the server’s CPU capacity.
How Parallel Calculation Works
Essbase’s parallel calculation divides the calculation workload along a dimension that produces independent calculation units. The most common parallelisation dimension is the Entity or the first sparse dimension — different entities can typically be calculated independently because the calculation for Entity A’s data does not depend on Entity B’s data being calculated first. Essbase’s calculator analyses the dependencies and assigns independent entity groups to separate calculation threads.
| Setting | Function | Typical Value |
|---|---|---|
| CALCPARALLEL [n] | Sets the number of parallel calculation threads | Number of CPU cores / 2 (leaving half for other processes) |
| CALCTASKDIMS [dimension] | Specifies which dimension is used to divide the calculation into parallel segments | Sparse dimension with most independent members (typically Entity) |
Parallel Calculation Constraints
Parallel calculation is not universally beneficial — it requires that the calculation can be genuinely partitioned into independent segments. Calculations with interdependencies between entities — where Entity A’s calculated value flows into Entity B’s calculation — cannot be parallelised across those entities, because the thread processing Entity B must wait for Entity A’s thread to complete before B can calculate. Attempting to parallelise a calculation with entity-to-entity dependencies produces incorrect results: Entity B may calculate before Entity A’s updated value is available, using a stale value for the Entity A input. Identifying which calculations can be safely parallelised requires dependency analysis of the business rule logic, not simply enabling parallel calculation and assuming it will be safe.
Parallel Calculation in Oracle EPM Cloud
In Oracle EPM Cloud, Essbase parallel calculation is available but constrained by Oracle’s cloud-managed Essbase configuration — the maximum thread count is set by Oracle based on the cloud compute instance’s CPU allocation, not by the client. Clients cannot increase the parallel thread count beyond Oracle’s cloud configuration for their tenant. For EPM Cloud applications where calculation performance is a problem, the effective remedy is Calc Script optimisation (reducing FIX scope to minimise the number of blocks per calculation) rather than parallel thread count tuning, because the latter is not a client-configurable parameter in the cloud model.
What Goes Wrong in Practice
The most common parallel calculation problem in production BSO environments is a race condition in a multi-step Calc Script where parallel threads executing Step 2 of the script read values calculated by Step 1 before all Step 1 threads have completed writing their results to the database. Step 1’s parallel threads write to different blocks simultaneously; Step 2’s parallel threads read from those same blocks. If a Step 2 thread reads a block that a Step 1 thread has not yet finished writing, Step 2 processes a stale or partial value. This produces calculation results that are incorrect and not reproducible — running the same Calc Script twice produces different results depending on the thread execution order. The solution is explicit synchronisation between script steps: a SET UPDATECALC OFF and a full AGG or CALC DIM between the parallel steps, ensuring all threads complete Step 1 before any thread begins Step 2.
How Loop Wise Solutions Configures Parallel Calculation
We evaluate parallel calculation settings for each business rule individually — analysing the dependency structure of the calculation to confirm that the targeted parallel dimension has no cross-entity dependencies, testing parallel execution in a test environment with representative data, and validating that the parallel and serial results are numerically identical before enabling parallel execution in production. Parallel calculation is enabled only after this validation; it is never enabled speculatively as a performance improvement measure without confirming calculation correctness.
