ASO — Aggregate Storage Option — is one of the two Essbase storage engines, designed for large, sparse data sets where the primary use case is high-performance aggregation and querying rather than interactive data input or complex calculation. ASO stores data in a compressed structure that does not organise data into blocks (as BSO does); instead, it stores only the cells that contain values and aggregates parent values dynamically at query time using pre-computed aggregate views — materialisations of frequently queried combinations that Essbase creates and maintains automatically.
ASO vs BSO Capability Comparison
| Capability | ASO | BSO |
|---|---|---|
| Write-back (data input) | No — read-only after load | Yes |
| Stored member formulas | No — dynamic calc only | Yes |
| Calc Script operations | Limited — aggregation-focused MDX | Full Calc Script support |
| Large member counts | Handles millions of members efficiently | Performance degrades above tens of thousands |
| Query-time aggregation | Native — pre-computed aggregate views | Requires explicit calculation first |
| Very sparse data sets | Efficient — stores only populated cells | Performance degrades for very sparse blocks |
| Typical EPM use | Reporting cubes; management dashboards | Input cubes; allocations; complex calculations |
Design Considerations
ASO cubes are populated from BSO cubes or external data sources through data pushes — and until the push is executed, the ASO cube reflects the data state at the time of the last push. The push frequency is the effective data currency for the ASO cube and must be designed to meet the reporting consumers’ needs.
Aggregate view creation is controlled through the ASO cube’s aggregate storage settings. When Oracle’s automatic aggregation is insufficient for query performance, custom aggregate views can be defined for specific dimension combinations that are queried frequently. Adding too many aggregate views increases the maintenance overhead and disk usage; the set of aggregate views should be driven by actual query patterns, not speculative optimisation.
What Goes Wrong in Practice
The specific failure unique to ASO deployments is enabling data input directly to an ASO cube for scenarios that require interactive planning input. Some EPM implementations attempt to use ASO for both storage and input — because ASO handles large member counts efficiently — and discover that data loaded into ASO cannot be written back through Smart View or Planning forms in the expected way. Users submit data through a form that appears to accept input, but the data is not persisted to the ASO structure correctly. The correct architecture for environments requiring both large member counts and interactive input is a BSO input cube with an ASO reporting cube fed by a data push, not a single ASO cube attempting to serve both functions.
How Loop Wise Solutions Handles This
In every EPM application design engagement, we produce an explicit BSO/ASO architecture decision document that specifies which cubes are BSO and which are ASO, with the rationale for each choice and the data flow between them. We do not allow the storage type decision to be deferred — it is a foundational architecture choice that determines the application’s behaviour, and reversing it after the application is built requires a full rebuild.
