You can view events related to parallel calculation in the application log:
To view the application log, see “Viewing Logs” in the Oracle Essbase Administration Services Online Help.
For each calculation pass, Essbase writes several types of information to the application log to support parallel calculation:
If you have enabled parallel calculation and Essbase has determined that parallel calculation can be performed, Essbase writes a message in the application log:
Calculating in parallel with n threads
n represents the number of concurrent tasks specified in CALCPARALLEL or SETCALCPARALLEL.
For each formula that prevents parallel calculation (forces serial calculation), Essbase writes a message to the application log:
Formula on ((or backward dependence from) mbr memberName prevents calculation from running in parallel.
memberName represents the name of the member where the relevant formula exists. You can look in the application log for such messages and consider removing the formula or, if possible, tagging the relevant member or members as Dynamic Calc so they do not feature in the calculation pass.
Essbase writes a message to the application log specifying the number of tasks that can be executed concurrently (based on the data, not the value of CALCPARALLEL or SETCALCPARALLEL):
Calculation task schedule [576,35,14,3,2,1]
The example message indicates that 576 tasks can be executed concurrently. After the 576 tasks complete, 35 more can be performed concurrently, and so on.
The benefit of parallel calculation is greatest in the first few steps and diminishes as fewer concurrent tasks are performed.
The degree of parallelism depends on the number of tasks in the task schedule. The greater the number, the more tasks that can run in parallel, and the greater the performance gains.
Essbase writes a message to the application log file indicating how many tasks are empty (contain no calculations):
[Tue Jun 27 12:30:44 2007]Local/CCDemo/Finance/essexer/ Info(1012681) Empty tasks [291,1,0,0,0,0]
In the example, Essbase indicates that 291 of the tasks at level 0 were empty.
If the ratio of empty tasks to the tasks specified in the calculation task schedule is greater than 50% (for example, 291 / 576), parallelism may not be giving you improved performance because of the high sparsity in the data model.
You can change dense-sparse assignments to reduce the number of empty tasks and increase the performance gains from parallel calculation.