Essbase Caches and Calc Performance

To optimize calculation performance, especially for large calculations, Essbase uses caches to coordinate memory usage. Ensure that the calculator cache, if used, is large enough to optimize calculations. Review how the index cache, data cache, dynamic calculator cache, and application cache may be relevant.

When calculating a cube, Essbase uses approximately 30 bytes of memory per member in the outline. So if the cube has 5,000 members, Essbase needs approximately 150 KB of memory to calculate it.

Note:

You can avoid excess memory use by combining calculation scripts. You can obtain good performance by using parallel calculation with a single calculation script. See Use Parallel Calculation.

Essbase uses memory to optimize calculation performance, especially for large calculations. The amount of memory used is not controllable, except by altering the size of the cube outline. However, you can ensure that the memory cache sizes enable Essbase to optimize the calculation.

Essbase uses the following caches to coordinate memory usage:

  • Calculator cache.

    When you first calculate a cube, the size of the calculator cache is significant for calculation performance. If possible, ensure that the calculator cache is large enough for Essbase to use the optimal calculator cache option.

    Refer to Size the Calculator Cache.

  • Dynamic calculator cache. Refer to Size the Dynamic Calculator Caches.

  • Index cache. If the cube is large, the default index cache is not large enough to provide optimum calculation performance. Refer to INDEXCACHESIZE application configuration property, or MaxL alter database set index_cache_size.

  • Data cache. Refer to DATACACHESIZE application configuration property, or MaxL alter database set data_cache_size.

  • Data file cache.

  • Application cache. If hybrid mode is used in block storage cubes, the application cache can help you manage memory usage for retrievals. The application cache is similar to the aggregate storage cache; for more information, refer to Aggregate Storage Cache.

Size the Calculator Cache

The best size for the Essbase calculator cache, if you use it, depends on the number and density of the sparse dimensions in the outline. Understanding the calculator cache bitmap will help you optimally size the calculator cache.

To optimize block management, Essbase can create a bitmap, whose size is controlled by the size of the calculator cache, to record and track data blocks during a calculation. The bitmap is a faster retrieval method for Essbase than disk I/O, particularly if you're calculating a cube for the first time, or calculating a cube with sparse data.

Essbase uses the calculator cache bitmap if the database has at least two sparse dimensions and either of these conditions is also met:

  • You calculate at least one full sparse dimension.

  • You specify the SET CACHE ALL command in a calculation script.

About the Calculator Cache Bitmap

For the calculator cache, Essbase separates sparse dimensions into two groups:

  • Bitmap dimensions: The sparse dimensions that Essbase fits into the bitmap until it is full. Each member combination of the sparse dimensions placed in the bitmap occupies 1 bit of memory. There must be enough space in the bitmap for every member combination of a sparse dimension for it to be placed in the bitmap.

  • Anchoring dimensions: The remaining one or more sparse dimensions in the database outline that do not fit into the bitmap.

Essbase starts with the first sparse dimension in the outline, and fits as many as possible into the bitmap. The dimensions that fit are the bitmap dimensions. Because the calculator cache controls the size of the bitmap, the number of sparse dimensions that can fit depends on the size of the calculator cache.

The remaining sparse dimensions are the anchoring dimensions. For anchoring dimensions, Essbase cannot use the bitmap to determine whether blocks exist.

To see which dimensions are anchoring dimensions and which are bitmap dimensions, use the SET MSG DETAIL calculation command to display bitmap information in the application log.

Carefully order the sparse dimensions in your outline so that as many dimensions as possible can be placed into the bitmap. Start with the dimension that contains the fewest members and continue until the dimension with the most members is last. This order allows more dimensions to fit into the bitmap and results in improved calculation performance.

Note:

The order of sparse dimensions in the outline also affects query performance. Refer to Design an Outline to Optimize Performance.

Essbase uses a single bitmap if there are multiple anchoring dimensions (or if the calculator cache is not large enough to support multiple bitmaps), and uses multiple bitmaps if there is one anchoring dimension. A single bitmap uses the least memory, but is less efficient than multiple bitmaps.

Multiple bitmaps use more memory, but are faster than using a single bitmap. One bitmap tracks child blocks and one tracks parent blocks. The performance improvement is particularly high when you are calculating the database for the first time.

The number of bitmaps used is determined by the maximum number of dependent parents for any members in the anchoring dimension. A member has one dependent parent, unless it has a shared member. For example, consider the Product dimension of the Sample.Basic database. The member Cola (100-10) has one parent, Colas (100). However, Diet Cola (100-20) has two parents, Diet Drinks (Diet) and Colas (100). No members of Product have more than two dependent parents. Therefore, if Product is the anchoring dimension, the maximum dependent parents is two.

Essbase chooses one of three options, as shown in the table below, for the calculation:

Table 34-2 Calculator Cache Options

Option Method Performance Rating

1

Single anchoring dimension, multiple bitmaps

1

2

Single anchoring dimension, single bitmap

2

3

Multiple anchoring dimensions, single bitmap

3

Essbase chooses the optimal performance method for a calculation, based on the size of the calculator cache. If the calculator cache size is too small for any of the above options, Essbase does not use a calculator cache. Calculation performance may be significantly impaired.

Enabling parallel calculation may change which calculator cache option is used. See Relationship Between CALCPARALLEL Parallel Calculation and Other Essbase Features.

Caution:

If you are calculating the database for the first time, the size of the calculator cache is particularly significant for calculation performance. If possible, ensure that the calculator cache is large enough for Essbase to use the optimal calculator cache option.

Determine the Calculator Cache Size

The optimum size of the calculator cache depends on the memory that the system has available and on the nature and configuration of the cube.

Using the following formula, you can calculate the calculator cache size required for Essbase to choose each of the three options in the Calculator Cache Options table above:

Calculator cache = Bitmap size in bytes * Number of bitmaps

where

Bitmap size in bytes = Max ((member combinations on the bitmap dimensions / 8), 4)

and where

Number of bitmaps = Maximum number of dependent parents in the anchoring dimension + 2 constant bitmaps

Note:

The minimum bitmap size is 4 bytes. If (member combinations on the bitmap dimensions/8) is less than 4 bytes, Essbase uses a bitmap size of 4 bytes.

Consider a sample cube with five sparse dimensions (S1 to S5):

Table 34-3 Example: Sample Cube with Five Sparse Dimensions

Sparse Dimension Number of Members Dependent Parents

S1

20

Not applicable

S2

20

Not applicable

S3

50

Not applicable

S4

50

Not applicable

S5

200

3

Use this sample cube for the following sample calculations:

  • Option 1: Single Anchoring Dimension, Multiple Bitmaps
  • Option 2: Single Anchoring Dimension, Single Bitmap
  • Option 3: Multiple Anchoring Dimensions, Single Bitmap

Option 1: Single Anchoring Dimension, Multiple Bitmaps

For this sample calculation, assume the following facts about a database:

  • Bitmap dimensions: S1, S2, S3, S4

  • Anchoring dimension: S5

  • Dependent parents in anchoring dimension: 3

Perform this calculation:

Bitmap size in bytes = (S1 * S2 * S3 * S4) / 8
                     = (20 * 20 * 50 * 50) / 8
                     = 125,000 bytes

Number of bitmaps = Maximum number of dependent parents in the anchoring dimension
                  = + 
                  = 2 constant bitmaps
                  = 3 + 2
                  = 5

Calculator cache = Bitmap size * Number of bitmaps
                 = 125,000 * 5
                 = 625,000 bytes

For Essbase to use multiple bitmaps for this database with one anchoring dimension, the calculator cache must be 625,000 bytes.

Option 2: Single Anchoring Dimension, Single Bitmap

For this sample calculation, assume the following facts about a database:

  • Bitmap dimensions: S1, S2, S3, S4

  • Anchoring dimension: S5

  • Dependent parents in anchoring dimension: Not applicable

Perform this calculation:

Bitmap size in bytes = (S1 * S2 * S3 * S4) / 8
                     = (20 * 20 * 50 * 50) / 8
                     = 125,000 bytes

Number of bitmaps = Single bitmap
                  = 1

Calculator cache = Bitmap size * Number of bitmaps
                 = 125,000 * 1
                 = 125,000 bytes

For Essbase to use a single bitmap for this database with one anchoring dimension, the calculator cache must be 125,000 bytes.

Option 3: Multiple Anchoring Dimensions, Single Bitmap

For this sample calculation, assume the following facts about a database:

  • Bitmap dimensions: S1, S2, S3

  • Anchoring dimensions: S4, S5

  • Dependent parents in anchoring dimensions: Not applicable

Perform this calculation:

Perform this calculation:

Bitmap size in bytes = (S1 * S2 * S3) / 8
                     = (20 * 20 * 50) / 8
                     = 2,500 bytes

Number of bitmaps = Single bitmap
                  = 1

Calculator cache = Bitmap size * Number of bitmaps
                 = 2,500 * 1
                 = 2,500 bytes

For Essbase to use a single bitmap for this database with multiple anchoring dimensions, the calculator cache must be 2,500 bytes.

The following table shows which calculator cache option Essbase uses, depending on the calculator cache size specified:

Table 34-4 Selection of Calculator Cache Option Based on Calculator Cache Size

Minimum Size Specified Option Selected

625,000 bytes

Option 1 (provides optimal performance)

125,000 bytes

Option 2

2,500 bytesFoot 1

Option 3

Footnote 1

If you specify a calculator cache size of less than 2,500 bytes, Essbase does not use a calculator cache during the calculation. Calculation performance may be significantly impaired.

You can check which calculator cache option Essbase is able to use by using the SET MSG SUMMARY command in a calculation script. Run the following calculation script on the empty cube:

SET MSG SUMMARY;
CALC ALL;

Essbase displays the calculator cache setting in the application log. See SET Commands for Calc Testing and Statistics.

The maximum calculator cache size that you can specify is 200,000,000 bytes. The default is 200,000 bytes. The calculator cache size that you choose depends on available memory and the configuration of the cube.

Note:

The sizes of the calculator, index, data file, and data caches usually have a greater effect on performance if the calculation is based more on aggregations and less on formula calculations.

If you are calculating the cube for the first time, the size of the calculator cache is particularly significant. If possible, ensure that the calculator cache is large enough for Essbase to use Option 1.

You can use the default calculator cache size, or you can set the size of the calculator cache within a calculation script. If you set the size from a calculation script, the setting is used only for the duration of the calculation script. See the calculation script SET CACHE command and CALCCACHE configuration setting.

Size the Dynamic Calculator Caches

For each cube that is open, Essbase allocates an area in a dynamic calculator cache for data blocks. To determine whether the dynamic calculator cache is being used effectively, review the application log and configuration settings.

Review Dynamic Calculator Cache Usage

The DYNCALCCACHEMAXSIZE configuration setting specifies the maximum size of each dynamic calculator cache on the Essbase Server. By default, the size is set to 20 MB. Essbase allocates area in a dynamic calculator cache for data blocks until the maximum memory area specified by the DYNCALCACHEMAXSIZE setting is allocated.

Essbase writes two messages to the application log for each data retrieval. In the following (truncated) example, the first message describes the total time required for the retrieval:

[2024-07-27T16:43:52.707+00:00] ... [EXEC_TIME: 0.53] Regular extractor completed successfully
[2024-07-27T16:43:52.707+00:00] ... Regular Extractor Big Block Allocs -- Dyn.Calc.Cache : [30] non-Dyn.Calc.Cache : [0]

If a dynamic calculator cache is used, a second message displays the number of blocks calculated within the data calculator cache (Dyn.Calc.Cache: [n]) and the number of blocks calculated in memory outside dynamic calculator cache (non-Dyn.Calc.Cache: [n]).

To determine whether the dynamic calculator cache is being used effectively, review both messages, and consider your configuration settings. For example, if the message indicates that blocks were calculated outside and in a dynamic calculator cache, you may increase the DYNCALCCACHEMAXSIZE setting.

If the specified maximum size is all you can afford, and if using memory outside the calculator cache to complete dynamically calculated retrievals results in unacceptable delays, set DYNCALCCACHEWAITFORBLK to TRUE.

You can use the query database MaxL statement with the performance statistics grammar to view a summary of dynamic calculator cache activity.

Change Dynamic Calculator Cache Size

There are five configuration settings that are relevant to dynamic calculator caches. The optimum values for these settings depend on the memory on the Essbase Server machine, the configuration of the Essbase databases, and the nature of user queries.

The following description of each configuration setting includes recommendations for how to determine values for your system. To match your site’s unique requirements, you may need to test and adjust the settings.

  • DYNCALCCACHEMAXSIZE: This setting specifies the maximum size Essbase can allocate to each dynamic calculator cache.

    Recommended setting value = C * S * U.

    • C is the value of the maximum number of blocks that Essbase needs to fix (get addressability to) when calculating one block. Usually, a value of 100 is good approximation for this value. This number can be a higher number if you are consolidating very large numbers of children in a formula calculation.

    • S is the size of the largest expanded block across all databases on the Essbase Server machine. To calculate the expanded block size, multiply the number of members (including Dynamic Calc members and dynamic time series members) in each dense dimension together for the number of cells in the block, and multiply the number of cells by the size of each member cell, 8 bytes.

      For example, consider the member count in dense dimensions in Sample.Basic (Label Only members are not counted):

      • 19 (Year, with 12 stored members and 7 Dynamic Calc members, including HTD and QTD)

      • 14 (Measures, with 8 stored members and 6 Dynamic Calc members)

      • 4 (Scenario, with 2 stored members and 2 Dynamic Calc members)

      S = 19 * 14 * 4 cells (8 bytes / cell) = 8512 bytes per block

      This number is shown in the application log as the logical block size.

    • U is the maximum number of expected concurrent users on the database that has the largest number of concurrent users.

      Assigning the value 0 (zero) to DYNCALCACHEMAXSIZE tells Essbase not to use dynamic calculator caches.

      By default, the size for this value is 20 MB (20,971,520 bytes).

  • DYNCALCCACHEWAITFORBLK: If Essbase uses all of the area allocated for a dynamic calculator cache, this setting tells Essbase whether to wait until space becomes available in the cache or to immediately write and calculate the blocks in memory outside the cache. If the cache is too small, it is possible for multiple threads to be in queue.

    Recommended setting value = FALSE (default value).

    Before setting to TRUE, try these alternatives:

    • Add physical memory to the server machine

    • Increase the value of DYNCALCCACHEMAXSIZE, test, and repeat until you verify that you cannot use any more memory for the dynamic calculator cache.

  • DYNCALCCACHEBLKTIMEOUT: If Essbase is to wait for available space in the dynamic calculator cache, this setting defines how long it waits.

    Recommended setting value = WT / B.

    • WT is the maximum tolerable wait time for a query; for example, 5 seconds.

    • B is the total number of logical blocks accessed in the largest query.

      To determine the value of B, check the messages in the application log for the largest number of Dyn.Calc.Cache “Big Block Allocs” for a query.

  • DYNCALCCACHEBLKRELEASE: If Essbase has waited the specified time and space still is not available in the dynamic calculator cache, this setting tells Essbase whether to write and calculate the blocks immediately outside the dynamic calculator cache or to create space by swapping out blocks and temporarily compressing the swapped blocks in a buffer.

    Recommended setting value = FALSE (default value).

    Set to TRUE only if you are experiencing severe memory shortage problems.

  • DYNCALCCACHECOMPRBLKBUFSIZE: If Essbase has waited the specified wait time and the DYNCALCCACHEBLKRELEASE setting is TRUE, this setting is the size of the dynamic calculator cache compressed-block buffer.

    Recommended setting value = (C * S) / 2

    where C is the value of the maximum number of blocks that Essbase needs to fix (get addressability to) when calculating one block, and S is the size of the largest expanded block across all databases on the machine. Calculate C and S the same way as described or the DYNCALCCACHEMAXSIZE setting.