Aggregation, decided once and correctly
Stored ahead of time or computed on demand: that choice, made per dimension, decides most of an application's speed. Oracle documented the decision rules; this page holds them with the mechanisms attached.
Note: In Planning, Oracle's module where budgets and forecasts are built, data lives in cubes, and how totals get computed, stored ahead of time or derived on demand, decides most of an application's speed. This page is that decision, made with Oracle's own design rules.
The whole module is mapped on the Planning index.
◆ The decision, from the doc, three designs, the leaf-level rule, and who can turn hybrid off.
| Design | When, per Oracle's hybrid design doc |
|---|---|
| Hybrid, all sparse parents dynamic | Small applications only. Everything computes on demand, nothing aggregates in batch, the app shrinks. |
| Hybrid, balanced | Large applications: some sparse parents stored, some dynamic. The doc is explicit that the balanced approach performs better at size. |
| Hybrid plus ASO | Very large applications with heavy reporting: hybrid for planning, an ASO cube for reporting, Smart Push and aggregate views between them. The doc is equally explicit that hybrid does not replace ASO for reporting purposes. |
One rule stands above the table: leaf-level members in sparse dimensions should not be dynamic, especially without a member formula. The doc gives the mechanism, not just the warning: the Essbase query then runs as suppress-missing rows and columns instead of suppress-missing blocks, and forms slow down. Newer Financial Consolidation, Planning Modules, custom, and FreeForm applications use hybrid cubes by default, and only Planning Custom and FreeForm can disable it, with dynamic uppers reverted to Store first, per the disable doc.
◆ Parallel calculation, honestly, serial for users, batch for parallel, and the log that tells the truth.
Parallel calculation deserves its own honesty. The practitioner canon and Oracle's guidance agree that end-user rules in multi-user applications should run serial, with SET CALCPARALLEL reserved for full sparse aggregations in batch, and nothing under roughly twenty seconds worth parallelizing at all. In hybrid cubes specifically, field testing finds parallel calculation gives little benefit in general, which follows from the design: dynamic parents removed the aggregations that parallelism existed to speed up. Where you do parallelize, Oracle's reference lists the formula patterns that quietly force serial execution, and the task log tells you when sparsity is defeating you: if more than half the scheduled tasks are empty, the task dimension is wrong. Read the log, every time.
The problem: Aggregations eat the batch window, and forms crawl.
What we build: We map every dimension's storage choice against the doc rules on this page, fix the violators, and measure.
What you get: The batch window gets its evening back, form times drop, and the choices are written down.
- dynamic
- Computed at retrieval. Shrinks the cube, moves cost to query time.
- balanced hybrid
- Some parents stored, some dynamic. The at-size answer.
- Smart Push
- Plan data moved to the ASO reporting cube as it changes.
- empty tasks
- Over half empty in the log means the task dimension is wrong.