OracleFree calculatorPDF, Excel, Word exportOracle Hyperion / EssbaseAll Oracle Hyperion and Essbase tools

Essbase BSO Block Size and Database Size Calculator

This calculator estimates block size, block counts and the size of the .pag and .ind files for an Oracle Essbase block storage (BSO) database from its dense and sparse member counts. It applies to Essbase 11.1.2.x and 21c BSO cubes.

Your numbers

For example Accounts. Count stored members only; exclude Dynamic Calc and label-only members.

For example Period.

Use 1 if you have only two dense dimensions.

For example Entity.

For example Product.

For example Version.

For example Years. Use 1 if unused.

0.5 %

Read from database statistics on an existing cube.

10 %

Your results

Expanded block size (KB)
53.125
Cells x 8 bytes. Oracle guidance has long been roughly 8 KB to 100 KB for most BSO cubes.
Estimated .pag size (GB)
0.8787
Cells per block
6,800
Potential blocks
30,000,000
Estimated existing blocks
150,000
Estimated stored bytes per block
6,290
Bitmap: 8 bytes per non-missing cell plus one bit per cell. Excludes block headers and fragmentation.
Estimated .ind size (MB)
16.0217
112 bytes per index entry, per the Essbase DBAG sizing method.

Planning estimate based on the Essbase Database Administrator's Guide sizing method (8 bytes per cell, 112 bytes per index entry). Real files are larger because of block headers, fragmentation and free space; compare with database statistics on a loaded copy.

Save results:

Estimated .pag size vs block existence

Sweeps Block existence (existing / potential blocks) from 0.1 to 5, holding your other inputs fixed.

Want your outline reviewed?

Send us your dimension counts and database statistics and we will comment on dense and sparse choices and expected size.

Optional. The tool and every export work without this. No spam.

Was this tool useful?

How to use it

Enter the number of stored members in each dense dimension and each sparse dimension. Stored means members that hold data: exclude Dynamic Calc members (they are calculated at retrieval and not stored in the block), label-only members and shared members. Then set block existence, the share of potential blocks that actually exist, and block density, the share of cells in an existing block that are not #Missing. On an existing cube, both figures are shown in the database statistics in Administration Services or the Essbase web interface, and should replace the defaults.

  • Dense dimensions define the block; sparse combinations define how many blocks exist.
  • Use 1 for unused dimension slots.
  • Re-run the estimate after changing which dimensions are dense.

The method behind the numbers

Essbase stores each cell as an 8-byte double, so the expanded block size is cells per block x 8 bytes, where cells per block is the product of stored dense members. Potential blocks are the product of stored sparse members; existing blocks are potential x existence. Each existing block has one index entry of 112 bytes in the .ind file, which is the figure Oracle's DBAG uses for index estimates. With bitmap compression, an existing block stores roughly 8 bytes per non-missing cell plus a bitmap of one bit per cell, which is how the stored size is estimated from density here.

Worked example and how to read it

With the defaults, 400 x 17 x 1 = 6,800 cells per block, or about 53 KB expanded, inside the commonly recommended 8 KB to 100 KB range. Sparse potential is 500 x 2,000 x 5 x 6 = 30 million blocks; at 0.5% existence that is 150,000 blocks. At 10% density each block stores about 6,290 bytes, so the .pag estimate is just under 1 GB and the .ind estimate about 16 MB. If the block size lands well above 100 KB, consider making a dense dimension sparse; if density is very low, the dense and sparse choice is probably wrong.

  • Block size too small: many blocks, large index, slow calcs.
  • Block size too large: high memory per block, poor cache use.
  • Existence above a few percent suggests a dimension may be better dense.

Frequently Asked Questions

How is Essbase block size calculated?

Multiply the number of stored members in each dense dimension to get cells per block, then multiply by 8 bytes per cell. For example 400 accounts x 17 periods = 6,800 cells, which is 54,400 bytes or about 53 KB. Dynamic Calc and label-only members are not counted.

What is a good Essbase block size?

Oracle's long-standing guidance for BSO is a block size of roughly 8 KB to 100 KB, with the right value depending on density, calc patterns and available memory. Test a few dense and sparse configurations on representative data and compare calc and retrieval times rather than relying on size alone.

What is an Essbase cube?

An Essbase cube is a multidimensional database inside an Essbase application, made of dimensions such as Accounts, Period, Entity and Product. In block storage (BSO), dense dimensions form data blocks and sparse dimension combinations index those blocks. Aggregate storage (ASO) cubes use a different structure and are not sized with this method.

Where do I find block density and existence for my cube?

Open the database properties or statistics in Essbase Administration Services or the Essbase web interface. They show existing blocks, potential blocks, block density and compression ratio. Use those values instead of the defaults here, and refresh them after a full restructure or data load.

If you want finance and planning users to ask questions of your Essbase cubes in plain English on your own servers, we can add a private AI layer over them.