Cache settings in Oracle Essbase BSO define the amounts of server memory (RAM) allocated for three types of in-memory data storage: the data cache (holds uncompressed data blocks in memory during calculation), the index cache (holds the block index in memory, enabling fast block location without disk reads), and the calculator cache (holds the block dependency graph used during calculation to determine which blocks must be calculated before others). Together, these three caches determine how much of the Essbase database’s working data set fits in memory during calculation operations — and calculations that can be performed entirely from cached data run significantly faster than calculations that must repeatedly read and write blocks from disk. Cache configuration is a primary performance tuning lever in on-premise Essbase environments, where the server’s physical RAM is the binding constraint.
The Three Essbase Caches
| Cache | Content | Default Size | Performance Impact of Undersizing |
|---|---|---|---|
| Data Cache | Uncompressed data blocks currently being read or written during calculation | 3 MB (very low) | Frequent disk I/O during calculation — blocks read from disk, calculated, written back, evicted from small cache repeatedly; calculation becomes I/O-bound |
| Index Cache | The Essbase block index (.ind file) — maps sparse dimension combinations to block locations | 1 MB | Repeated disk reads of index segments — block location lookups require disk access instead of memory access; query performance degrades |
| Calculator Cache | Block dependency graph during CALC ALL or AGG operations | 20 MB | Calculator must swap dependency graph to disk — parallel calculation efficiency degrades; calculation sequence resolution slows |
Cache Sizing Guidelines
Oracle’s general guidance for Essbase cache sizing reflects the database’s characteristics. The index cache should be large enough to hold the entire index file in memory — the index file size is visible in the Essbase Administration Services statistics and typically ranges from a few MB to several hundred MB depending on block count. The data cache is typically sized at 10-20% of the application’s total data size (the combined size of all .pag files) for applications where full-database calculations are performed regularly — though the correct size is ultimately determined by the calculation pattern, not a percentage formula. The calculator cache should be at least 10 MB and scales with the number of sparse members and the complexity of the calculation dependency graph.
Cache Settings in Oracle EPM Cloud
In Oracle EPM Cloud, clients do not directly configure Essbase cache settings — Oracle manages the Essbase infrastructure and applies cache configurations as part of the SaaS service. Oracle’s cloud-managed Essbase environment uses Oracle’s standard configurations scaled to the cloud compute instance size. For clients experiencing slow business rule execution in EPM Cloud, the performance remediation is through application design improvements (FIX scope reduction, dense/sparse redesign) rather than cache configuration changes, because cache tuning is not available as a client-configurable parameter in the cloud model.
What Goes Wrong in Practice
The specific cache misconfiguration that most commonly produces severe calculation performance degradation in on-premise Hyperion environments is a data cache that remains at its installation default of 3 MB for a large BSO application whose block size is 50 KB. With a 3 MB data cache, only 60 blocks (3 MB / 50 KB per block) can be held in memory simultaneously during calculation. If a business rule requires processing 10,000 blocks, each block must be read from disk, calculated, written back to disk, and then evicted to make room for the next 60 blocks — 10,000 / 60 = 167 complete cache cycles of disk I/O. On a database server with rotational disk storage, this pattern produces business rule execution times of hours for calculations that would complete in minutes with an appropriately sized data cache holding several thousand blocks in memory simultaneously.
How Loop Wise Solutions Tunes Essbase Caches
In Hyperion performance assessment engagements, we measure the Essbase database statistics — index file size, total data size, block size, and block count — and calculate the optimal cache sizes for each application. We implement the cache changes in the test environment first, validate calculation performance improvement against baseline, and deploy to production during a scheduled maintenance window with the performance improvement evidence documented.
