The potential number of data blocks is the maximum number of data blocks possible in the database.

If the database is already loaded, you can see the potential number of blocks on the Statistics tab of the Database Properties dialog box of Administration Services.

If the database is not already loaded, you must calculate the value.

Example

The Sample.Basic database contains the following sparse dimensions:

Therefore, there are 19 * 25 = 475 potential data blocks.

As compared with the potential number of blocks, existing blocks refers to those data blocks that Essbase actually creates. For Essbase to create a block, at least one value must exist for a combination of stored members from sparse dimensions. Because many combinations can be missing, the number of existing data blocks is usually much less than the potential number of data blocks.

If the database is not already loaded, you must estimate a value.

Example

The following three examples show different levels of sparsity and assume 100,000,000 potential data blocks:

The potential, expanded (uncompressed) size of each data block is based on the number of cells in a block and the number of bytes used for each cell. The number of cells is based on the number of stored members in the dense dimensions. Essbase uses eight bytes to store each intersecting value in a block.

If the database is not loaded, you must estimate the value.

Example

The Sample.Basic database contains the following dense dimensions:

Perform the following calculations to determine the potential size of a data block in Sample.Basic:

12 * 8 * 2 = 192 data cells 

192 data cells 
* 8 bytes 
= 1,536 bytes (potential data block size)

Compression affects the actual disk space used by a data file. The four types of compression (bitmap, run-length encoding (RLE), zlib, and index-value) affect disk space differently. For a discussion of data compression unrelated to estimating size requirements, see Data Compression.

If you are not using compression, or if you have enabled RLE compression, skip this calculation and proceed to Stored Data Files.

Example

Assume an expanded block size of 1,536 bytes and a block density of 25% (.25):

1,536 bytes 
* .25 
= 384 bytes (compressed block size)

The size of the stored database depends on whether the database is compressed and the compression method chosen for the database. Essbase provides five compression-method options: bitmap, run-length encoding (RLE), zlib, index-value, and none.

Calculating the size of a compressed database is complex for a number of reasons including the following:

For a comprehensive discussion of data compression unrelated to estimating size requirements, see Data Compression. The calculations in this discussion are for estimation purposes only.

The calculation for the space required to store the compressed data files (essxxxxx.pag) uses the following factors:

Number of blocks * (72 bytes + size of expanded data block)

Number of blocks 
* (72 bytes 
+ (average size in bytes of an expanded data block)
* (1/64 + proportion of cells that are not #Missing))

1000 * (72 + 2000 * (1/64 + 0.7) )
= 1000 * 1503
= 1,503,000 bytes (approximately)

Number of blocks * (72 bytes 
+ (1.5 * database density * expanded data block size)

The calculation for the space required to store the index files (essxxxxx.ind) uses the following factors:

The minimum size for the index is 8,216,576 bytes (8 MB). To calculate the size of a database index, including all index files, perform the following calculation:

number of existing blocks * 112 bytes = the size of database index

In the cell labeled DF in Table 150, Worksheet for Estimating Disk Requirements for a Database   , write whichever is the larger number, the results of the calculation or 8,216,576.

Example

Assume a database with 15,000,000 blocks.

15,000,000 blocks 
* 112 
= 1,680,000,000 bytes

If you are using bitmap or RLE compression, some fragmentation occurs, the amount of which is based on individual database and operating system configurations and cannot be precisely predicted.

As a rough estimate, calculate 20% of the compressed database size (value DE from Table 150, Worksheet for Estimating Disk Requirements for a Database   ) and write the result to the cell labeled DG in the same table.

Example

Calculating fragmentation allowance assuming a compressed database size of 5,769,000,000 bytes:

5,769,000,000 bytes 
* .2 
= 1,153,800,000 bytes

Three processes create temporary work areas on the disk:

To create these temporary work areas, Essbase may require disk space equal to the size of the entire database. Restructuring and migration need additional work space the size of the outline. Because none of these activities occur at the same time, a single allocation can represent all three requirements.

To calculate the size of a work area used for restructuring, migration, and recovery, calculate the sum of the sizes of the following database components from Table 150, Worksheet for Estimating Disk Requirements for a Database   :

Use the following formula to calculate the size of the work area:

work area = size of compressed data files 
+ size of index files 
+ fragmentation allowance 
+ outline size 

Write the result of this calculation to the cell labeled DI in Table 150, Worksheet for Estimating Disk Requirements for a Database   .

You can use the Linked Reporting Objects (LROs) feature to associate objects (also called artifacts) with data cells. The objects can be flat files, HTML files, graphics files, and cell notes. See Linking Objects to Essbase Data.

Two aspects of LROs affect disk space:

Example

Assume the database uses 1,500 LROs, which comprise the following:

Perform the following calculations:

Before you start the estimate, calculate factors to be used in calculating the estimate.

Table 153, Factors Used to Calculate Database Memory Requirements lists sizing factors with references to sections in this chapter and other chapters that provide information to determine these sizes. Go to the section indicated, perform the calculation, and return to Table 153. Write the size, in bytes, in the Value column this table.

Later in this chapter, you can refer to Table 153 for values to use in various calculations.

The calculations in this chapter do not account for other factors that affect how much memory is used. The following factors have complex implications and are not included in the discussion:

The attribute association area included in disk space calculations is not a sizing factor for memory. Calculate only the main area of the outline.

For memory size requirements, outline size is calculated using the following factors:

If the database includes few aliases or very short aliases and short member names, use a smaller number in the 300 byte–400 byte range. If you know that the names or aliases are very long, use a larger number within this range.

Because the name-length factor is an estimated average, the following formula provides only a rough estimate of the main area of the outline:

memory size of outline 
= number of members 
* name-length factor

Example

Assuming that the outline has 26,000 members and a median name-length, use the following calculation to estimate the outline size used in memory:

26,000 members 
* 350 bytes per member 
= 9,100,000 bytes

At startup, Essbase sets aside memory for the index cache, the size of which can be user-specified. To determine the size of the index cache, see Sizing Caches and write the size in the cell labeled MB in Table 152, Worksheet for Estimating Memory Requirements for a Database.

Essbase uses additional memory while it works with the caches.

The calculation for this cache-related overhead uses the following factors:

The term logical block refers to an expanded block in memory.

Example

Excluding Label Only and shared members, the dense dimensions in Sample.Basic contain 17 (Year), 14 (Measures), and 4 (Scenario) members. The calculation for the cell count of a logical block in Sample.Basic:

17 * 14 * 4 = 952 cells

At application startup, Essbase sets aside an area of memory based on the following factors:

Example

Assuming 20 threads for the Sample.Basic database, the startup area in memory required for data structures is calculated:

20 threads 
* ((79 members * 26 bytes) + (952 cells * 36 bytes)) 
= 726,520 bytes 726,520 bytes 
/ 1,048,576 bytes = .7 MB 

Essbase processes requests for database information (queries) from many sources. For example, Essbase processes queries from Oracle's Hyperion® Essbase® Spreadsheet Toolkit and from Report Writer. Essbase uses additional memory when it retrieves the data for these queries, especially when Essbase must perform dynamic calculations to retrieve the data. This section describes Essbase memory requirements for query processing.

Essbase is a multi-threaded application in which queries get assigned to threads. Threads are automatically created when Essbase is started. In general, a thread exists until you shut down Essbase Server. See Multithreading.

As Essbase processes queries, it cycles through available threads. For example, assume that 20 threads are available at startup. As each query is processed, Essbase assigns each succeeding query to the next sequential thread. After it has assigned the 20th thread, Essbase cycles back to the beginning, assigning the 21st query to the first thread.

While processing a query, a thread allocates some memory, and then releases most of it when the query is completed. Some memory is released to the operating system, and some is released to the dynamic calculator cache for the database being used. However, the thread holds on to a portion of the memory for possible use in processing subsequent queries. As a result, after a thread has processed its first query, the memory held by the thread is greater than it was when Essbase first started.

Essbase uses the maximum memory for query processing when both conditions are true:

In the example where 20 threads are available at startup, the maximum amount of memory is used for queries when at least 20 queries have been processed and the maximum number of simultaneous queries are in process.

Calculating the Maximum Additional Memory Required

Use the following variables when you calculate the formula in Estimating the Maximum Memory Usage for a Query Before and After Processing:

Determining the Total Number of Threads

The potential number of threads available is based on the number of licensed ports that are purchased. The actual number of threads available depends on settings that you define for the Agent or the server. Use the number of threads on the system as the value for Total#Threads in later calculations.

Estimating the Maximum Number of Concurrent Queries

Determine the maximum number of concurrent queries and use this value for Max#ConcQueries in later calculations. This value cannot exceed the value for Total#Threads.

Estimating the Maximum Memory Usage for a Query Before and After Processing

The memory usage of individual queries depends on the size of each query and the number of data blocks that Essbase needs to access to process each query. To estimate the memory usage, calculate the additional memory Essbase uses during processing and after processing each query.

Choose several queries that you expect to use the most memory. Consider queries that must process large numbers of members; for example, queries that perform range or rank processing.

Because this calculation method assumes that all of the concurrent queries are maximum-sized queries, the result may exceed your actual requirement. It is difficult to estimate the actual types of queries that will be run concurrently.

To adjust the memory used during queries, you can set values for the retrieval buffer and the retrieval sort buffer. See Setting the Retrieval Buffer Size and Setting the Retrieval Sort Buffer Size.

If you cannot perform this test with actual queries, you can calculate a rough estimate for operational query requirements. Requirements for each retrieval vary considerably. Generally, this estimate uses the following fixed factors:

This estimate also uses the following variables:

You can then use the following two calculations for the memory needed for retrievals:

Summarize the calculations and write the result, in bytes, to the cell labeled ME in Table 152, Worksheet for Estimating Memory Requirements for a Database.

Example

To estimate the maximum memory needed for concurrent queries, assume the following values for this example:

Estimated memory for retrievals:

184,000 bytes + (20 concurrent inquiries
* (10,240 bytes + 20,480 bytes + 144,000 bytes
+ 761,600 bytes + 3,145,728 bytes + 400,000 bytes))
= 75,824,960 bytes

For existing calculation scripts, you can use the memory monitoring tools provided for the operating system on the server to observe memory usage. Run the most complex calculation and notice the memory use before and while running the calculation. Calculate the difference and use that figure as the additional memory requirement for the calculation script.

For a comprehensive discussion of calculation performance, see Optimizing Calculations.

If you cannot perform a test with a calculation script, you can calculate a very rough estimate for the operational requirement of a calculation by adding the following values:

For the total calculation requirement, summarize the memory needed for all calculations that will be run simultaneously and write that total to the cell labeled MF in Table 152, Worksheet for Estimating Memory Requirements for a Database.