In This Section:
If data blocks are much larger than 100 KB, Intelligent Calculation does not work effectively. See Understanding Intelligent Calculation.
To optimize calculation performance and data storage, balance data block density and data block size by rearranging the dense and sparse dimension configuration of the database. Keep these suggestions in mind:
You may improve calculation performance by changing the order of standard (not attribute) sparse dimensions in the database outline. Order standard sparse dimensions by the number of members they contain, placing the dimension that contains the fewest members first. This arrangement provides many possible improvements, depending on the site:
The calculator cache functions more effectively, providing approximately a 10% performance improvement if you have a database outline with a large dimension (for example, one containing 1000 members).
To optimize calculation performance when you load data incrementally, make the dimension tagged as time a sparse dimension. If the time dimension is sparse, the database contains a data block for each time period. When you load data by time period, Essbase accesses fewer data blocks because fewer blocks contain the relevant time period. Thus, if you have Intelligent Calculation enabled, only the data blocks marked as dirty are recalculated. For example, if you load data for March, only the data blocks for March and the dependent parents of March are updated.
However, making the time dimension sparse when it is naturally dense may significantly increase the size of the index, creating possibly slower performance due to more physical I/O activity to accommodate the large index.
If the dimension tagged as time is dense, you still receive some benefit from Intelligent Calculation when you do a partial data load for a sparse dimension. For example, if Product is sparse and you load data for one product, Essbase recalculates only the blocks affected by the partial load, although time is dense and Intelligent Calculation is enabled.
For information on incremental loads, see Loading Data into Aggregate Storage Databases.
Calculation performance may be affected if a database outline has multiple flat dimensions. A flat dimension has very few parents, and each parent has many thousands of children; in other words, flat dimensions have many members and few levels.
You may achieve significant improvements in calculation performance by carefully grouping formulas and dimensions in a calculation script. In this way, you can ensure that Essbase cycles through the data blocks in the database as few times as possible during a calculation.
Order commands in calculation scripts to make the database calculation as simple as possible. Consider applying all formulas to the database outline and using a default calculation (CALC ALL). This method may improve calculation performance.
SET MSG DETAIL also provides an information message every time Essbase calculates a data block. SET MSG DETAIL is useful for reviewing the calculation order of data blocks and for testing intelligent recalculations.
Because SET MSG DETAIL causes a high processing overhead, use it only during test calculations.
You can use the SET NOTICE calculation command in a calculation script to display calculation completion notices that tell you what percentage of the database has been calculated. You can use the SET MSG SUMMARY command with the SET NOTICE command to show calculation progress between completion notices. Completion notices do not significantly reduce calculation performance, except when used with a very small database.
You can simulate a calculation using SET MSG ONLY in a calculation script. A simulated calculation produces results that help you analyze the performance of a real calculation that is based on the same data and outline.
By running a simulated calculation with a command such as SET NOTICE HIGH, you can mark the relative amount of time each sparse dimension takes to complete. Then, by performing a real calculation on one or more dimensions, you can estimate how long the full calculation will take, because the time a simulated calculation takes to run is proportional to the time that the actual calculation takes to run.
For example, if the calculation starts at 9:50:00 AM, and the first notice is time-stamped at 09:50:10 AM and the second is time-stamped at 09:50:20 AM, you know that each part of the calculation took 10 seconds. If you then run a real calculation on only the first portion and note that it took 30 seconds to run, you know that the other portion also will take 30 seconds. If there were two messages total, then you would know that the real calculation will take approximately 60 seconds (20 / 10 * 30 = 60 seconds).
To perform a simulated calculation:
SET MSG ONLY; SET NOTICE HIGH; CALC ALL;
CALC DIM (DENSE_DIM1, DENSE_DIM2, …);
CALC DIM (SPARSEDIM1, SPARSEDIM2, …);
To estimate total calculation time:
See Table 175.
Table 175. Sample Intervals Between Log Messages
When these factors are present, this estimating technique more closely predicts calculation time when Essbase reaches 30%–40% of the simulated calculations (30%–40% of the messages generated by SET NOTICE HIGH). See the Oracle Essbase Technical Reference.
Using SET MSG ONLY as a calculation-time estimating technique should be validated against later CALCNOTICE intervals. The results of this estimating technique vary because of the following chain of influences:
Another factor that can make actual results diverge significantly from predicted is the outline structure. Calculations based on CALCNOTICE intervals assume evenly balanced processing time throughout the outline. Factors that can skew this balance include the following situations:
To estimate the database size resulting from a calculation using interactive mode:
essmsh login username password; alter system load application appname; alter application appname load database dbname;
query database appname.dbname get estimated size;
If you need to estimate partitions, you must query Essbase for a database size estimate on every partition and add the results. If you query for the size of only the source database, the estimate includes only the data on the source database server.
You may achieve significant improvements in calculation performance by carefully using formulas in the database outline. For example, you may achieve improved calculation performance by placing formulas on members in the database outline instead of placing the formulas in a calculation script. See Developing Formulas for Block Storage Databases.
Using the database outline to roll up values is more efficient than using a formula to calculate values. For example, the consolidation of members 100-10, 100-20, and 100-30 into member 100, as shown in Figure 141, Consolidation Example, is more efficient than applying the following formula to member 100:
100-10 + 100-20 + 100-30
If you use a simple formula, and block size is not unusually large, you can place the formula on a member of either a sparse or a dense dimension without significantly affecting calculation performance. The bigger the block size, the more impact simple formulas have on calculation performance. For a discussion of the relationship between block size and calculation performance, see Block Size and Block Density.
Does not use relationship or financial functions. For example, a simple formula cannot use @ANCESTVAL, @NEXT, @PARENTVAL, @SHIFT, @ACCUM, or @GROWTH. For a complete list of relationship and financial functions, see the Oracle Essbase Technical Reference.
For information on how formulas affect calculation performance, see Bottom-Up and Top-Down Calculation.
Use the FIX command in a calculation script to calculate only required data blocks. See Using the FIX Command.
Uses relationship or financial functions; for example, @ANCESTVAL, @NEXT, @PARENTVAL, @SHIFT, @ACCUM, or @GROWTH. For a complete list of relationship and financial functions, see the Oracle Essbase Technical Reference.
When applied to sparse dimension members, complex formulas create more calculation overhead and therefore slow performance. This problem occurs because the presence of complex formulas requires Essbase to perform calculations on all possible as well as all existing data blocks related to the member with the complex formula. The presence of a relationship or financial function on a sparse dimension member causes Essbase to perform calculations on all blocks, possible as well as existing, increasing the overhead even more.
For a discussion about how complex formulas affect calculation performance, see Bottom-Up and Top-Down Calculation.
If a database has 10 existing data blocks and 100 potential data blocks, the overhead is as much as ten times what it would be without the complex formula (depending on the outline structure and other factors), as many as 90 extra blocks to read and possibly write to.
You can use the SET FRMLBOTTOMUP calculation command to optimize the calculation of formulas in sparse dimensions in large database outlines. With this command, you can force a bottom-up calculation on sparse member formulas that otherwise would be calculated top-down. See Forcing a Bottom-Up Calculation.
Forcing a bottom-up calculation on a top-down formula enables efficient use of the CALC ALL and CALC DIM commands. Review the discussions of the SET FRMLBOTTOMUP calculation command and the CALCOPTFRMLBOTTOMUP configuration setting in the Oracle Essbase Technical Reference.
California = 120;
In this formula, California is a member in a sparse dimension and 120 is a constant value. Essbase automatically creates all possible data blocks for California and assigns the value 120 to all data cells. Many thousands of data blocks may be created. To improve performance, create a formula that does not create unnecessary values.
To assign constants in a sparse dimension to only those intersections that require a value, use FIX in a manner similar to the following example:
FIX(Colas,Misc,Actual) California = 120; ENDFIX
In this example, Colas is a member of the sparse dimension, Product; Actual is a member of the dense dimension, Scenario; and Misc is a member of the dense dimension, Measures. The value 120 is assigned to any intersection of California (in the Market dimension), Actual (in the Scenario dimension), Misc (in the Measures dimension), Colas (in the Product dimension), and any member in the Year dimension, because a specific member of Year is not specified in the script.
Because Sample.Basic includes only two sparse dimensions, this example affects only one block. If more sparse dimensions existed, Essbase would ensure data blocks for all combinations of the sparse dimensions with California and Colas, creating blocks if necessary. Within the new blocks, Essbase sets Measures and Scenario values (other than those assigned the value 120) to #MISSING.
If you assign nonconstant values to members of a sparse dimension, blocks are created based on the Create Blocks on Equations setting. The Create Blocks on Equations setting is defined at the database level, as a database property. (See Nonconstant Values.)
Within calculation scripts, you can temporarily override the Create Blocks on Equations setting. Consider the effects of the following calculation when West does not have a value and Create Blocks on Equations is enabled:
West = California + 120;
Unneeded blocks may be created for all sparse-member intersections with West, even if the corresponding block value is #MISSING for all of the children of West. Especially in a large database, creation and processing of unneeded blocks requires additional processing time.
To control creation of blocks when you assign nonconstant values to members of a sparse dimension, use the SET CREATEBLOCKONEQ ON | OFF calculation command, as shown in the following script:
FIX (Colas); SET CREATEBLOCKONEQ OFF West = California + 120; SET CREATEBLOCKONEQ ON East = “New York” + 100; ENDFIX
Because the Create Block on Equation setting is disabled at the beginning of the script, West blocks are created only when values exist for the children of West. Later, because the Create Block on Equation setting is enabled, all blocks for East are created.
For faster calculation script performance, use FIX in the calculation script to qualify the use of a formula rather than a formula that includes a cross-dimensional operator on the left of an equation.
FIX(Jan) Sales = Sales * .05; ENDFIX
Sales(Sales -> Jan = Sales -> Jan * .05;)
As Essbase cycles through the database, it calculates the formula for every member combination that includes a member from the dimension tagged as time (Jan, Feb, Mar, and so on), although only January combinations need to be calculated.
See Using the FIX Command and the Oracle Essbase Technical Reference.
FIX(Sales) Budget = Actual * 1.1; ENDFIX FIX(Expenses) Budget = Actual * .95; ENDFIX
Use the DATACOPY calculation command to create and then calculate the required blocks. See Using DATACOPY to Copy Existing Blocks.
FIX(Sales, Expenses) Budget (Sales = Sales -> Actual * 1.1; Expenses = Expenses -> Actual * .95;) ENDFIX
Formulas in a block storage outline can have dependencies on one another such that they cause a nested execution of formulas within one or more blocks. Such formulas are called recursive formulas. Sometimes recursive formulas result in large or unending loops that result in abnormal termination of the server.
To avoid abnormal termination, you can use the CALCLIMITFORMULARECURSION configuration setting to stop a formula execution that reaches beyond a default number of execution levels. See the Oracle Essbase Technical Reference.
A top-down calculation is less efficient than a bottom-up calculation, because more blocks are calculated than is necessary. Although a top-down calculation is less efficient than a bottom-up calculation, top-down calculations are necessary in some cases to ensure that calculation results are correct.
For a bottom-up calculation, Essbase determines which data blocks must be calculated before it calculates the database. Essbase then calculates only the blocks that must be calculated. The calculation begins with the existing block with the lowest block number and works up through each block in number order until the existing block with the highest block number is reached. See Block Calculation Order.
For simple formulas, Essbase does a bottom-up calculation to determine which blocks must be calculated before running the full calculation. For example, for a simple formula on a member (such as A = B + C), A is calculated only if B or C exists in the database. That is, the dependency of the formula on B and C is known before the calculation is started.
Before starting a calculation, Essbase searches the database outline and marks complex formulas that require top-down calculation; for example, a member formula that contains a cross-dimensional reference. When Essbase reaches a member with a top-down formula, it does a top-down calculation for the member.
When a formula on a member is complex, all possible blocks for the member must be examined to see if an existing block must be changed or a new block created; it is difficult to determine the dependency that blocks have on other blocks before the start of the calculation. The top-down method slows calculation performance because Essbase must search for appropriate blocks to calculate to execute the formula.
A = B -> D + C -> D
To force a bottom-up calculation, use a tool:
Forcing a bottom-up calculation on a formula usually increases performance time. If the formula contains complex functions (for example, range functions) or if the formula's dependencies are not straightforward, a bottom-up calculation may produce results different from those of a top-down calculation.
Before changing the setting CALCOPTFRMLBOTTOMUP or using the calculation script command SET FRMLBOTTOMUP in a production environment, check the validity of calculation results by comparing, relative to the same data, the results of a bottom-up calculation and the results of a top-down calculation.
Hybrid aggregation mode is available for block storage databases. Hybrid aggregation for block storage databases means that wherever possible, block storage data calculation executes with efficiency similar to that of aggregate storage databases. See Using Hybrid Aggregation.
See also the ASODYNAMICAGGINBSO configuration setting topic in the Oracle Essbase Technical Reference.
The following section describes the caches that are used with block storage databases. For information about the aggregate storage cache, see Managing the Aggregate Storage Cache.
When calculating a database, Essbase uses approximately 30 bytes of memory per member in the database outline. So if the database has 5,000 members, Essbase needs approximately 150 KB of memory to calculate the database.
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 Using 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 database outline. However, you can ensure that the memory cache sizes enable Essbase to optimize the calculation.
Application cache. If hybrid aggregation mode is used in block storage databases, the application cache can help you manage memory usage for retrievals. The application cache is similar to the aggregate storage cache; for more information, see Managing the Aggregate Storage Cache.
When you first calculate a database, 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.
See Sizing Caches. Read the entire topic before making changes.
When a block is calculated, Essbase locks the block and all blocks that contain the children of the block. Essbase calculates the block and then releases the block and the blocks containing the children.
By default, Essbase locks up to 100 blocks concurrently when calculating a block. This number of block locks is sufficient for most database calculations. If you are calculating a formula in a sparse dimension, Essbase works most efficiently if it can lock all required child blocks concurrently. Therefore, when calculating a formula in a sparse dimension, you may want to set a lock number higher than 100 if you are consolidating very large numbers of children (for example, more than 100). By increasing the number, you ensure that Essbase can lock all required blocks, and performance is not impaired.
For consolidations in a sparse dimension, block locking is not a consideration, because Essbase does not need to lock all blocks containing children concurrently.
You can use the SET LOCKBLOCK command in a calculation script along with the CALCLOCKBLOCK setting in the essbase.cfg file to specify the maximum number of blocks that Essbase can lock concurrently when calculating a block. If you do not modify the default setting, and the default 100 blocks is not sufficient during calculation, the calculation may require more time than expected.
Essbase uses the block locking system to manage concurrent access to users. This system ensures that only one user at a time can update or calculate a particular data block. How Essbase handles locking blocks and committing data depends on the isolation level setting.
When Essbase calculates a data block, it creates an exclusive lock; other users cannot update or calculate it, but they can have read-only access. When Essbase finishes the calculation, it releases the block. Other users can then update the block if they have the appropriate security access.
When a user is updating a data block, the block is locked. If a database calculation requires a data block that is being updated by another user, the calculation waits for one of the following conditions:
You can improve performance significantly by tagging an accounts dimension member as two-pass in the database outline, if it is appropriate for the application. The combination of data and calculation needs may require the use of a calculation script to calculate a formula twice, instead of two-pass tagging, to preserve accuracy.
Use these sections to understand more about two-pass calculation. Decide whether you can tag an accounts dimension member as two-pass to improve performance, or whether you must use a calculation script to calculate a formula twice. This section also provides information about how to enable two-pass calculation or create a calculation script for two-pass calculation.
For information about the interaction of two-pass calculation and attribute members, see Table 17, Differences Between Attribute and Standard Dimensions.
Whenever possible, Essbase calculates two-pass formulas at the data block level, calculating the two-pass formulas simultaneously as the main calculation. Thus, Essbase need not do an extra calculation pass through the database. However, in some situations, Essbase needs an extra calculation pass through the database.
How Essbase calculates the two-pass formulas depends on whether there is a dimension tagged as time as well as a dimension tagged as accounts and on the dense-sparse configuration of the time and account dimensions.
Profit % = Profit % Sales
Assume that Table 176 shows a subset of a data block with Measures and Year as dense dimensions. Measures is tagged as accounts, and Year is tagged as time. The AGGMISSG configuration setting is turned off (the default).
Data values have been loaded into the input cells. Essbase calculates the cells in which the numbers 1 through 7 appear, in that order. For example, Profit % -> Jan is calculated first; Profit% -> Qtr1 has multiple consolidation paths.
Table 176. Two-Pass Calculation Example: Data and Calculation Order
Measures -> Year
For information on how cell calculation order depends on database configuration, see Cell Calculation Order.
Essbase calculates Profit % -> Qtr1 by adding the values for Profit % -> Jan, Profit % -> Feb, and Profit % -> Mar (7 above). This addition of percentages produces the value 125%, which is not the correct result.
For information about multiple calculation passes, see Calculation Passes.
Two scenarios are described in detail in the following sections. If you are using Intelligent Calculation, use the scenario that matches the configuration of the database; each scenario tells you how to ensure that Essbase accurately calculates two-pass formulas.
These scenarios require that you understand the concepts of Intelligent Calculation. See Understanding Intelligent Calculation.
When you tag a member formula as two-pass in the outline, Essbase does the two-pass calculation while each data block is being calculated. However, when you repeat a formula in a calculation script, Essbase must read the data blocks and write them to memory to recalculate the formula.
Essbase calculates the database and then does an extra calculation pass to calculate the two-pass formulas. Even though all data blocks are marked as clean after the first database calculation, Essbase ignores the clean status on the blocks that are relevant to the two-pass formula and recalculates these blocks.
After the first calculation, Essbase has marked all data blocks as clean for the purposes of Intelligent Calculation. In a second calculation pass through the database, Essbase recalculates the required data blocks for the two-pass formulas. However, because the second calculation is a partial calculation of the database, Essbase does not mark the recalculated blocks as clean. When you recalculate the database with Intelligent Calculation turned on, these data blocks may be recalculated unnecessarily.
If the database configuration allows Essbase to use Scenario B, consider using a calculation script to perform two-pass formula calculations. If you use a calculation script, Essbase still does an extra calculation pass through the database; however, you can ensure that Essbase has marked all the data blocks as clean after the calculation. See Creating Calculation Scripts for Two-Pass and Intelligent Calculation.
Although tagging an accounts member as two-pass may bring performance benefits, some applications cannot use this method. Check these qualifications to see whether you should apply a two-pass tag or create a calculation script that performs a calculation twice for best performance and accuracy:
You can tag a member as two-pass if it is in a dimension tagged as accounts. When you perform a default calculation on the database, Essbase automatically recalculates any formulas tagged as two-pass if they are in the dimension tagged as accounts in the database outline.
You can tag a member as two-pass if it is a Dynamic Calc or Dynamic Calc and Store member of any dimension. See Dynamically Calculating Data Values.
You may need to use a calculation script to calculate a two-pass formula to obtain accurate results, even if the two-pass tag would provide performance benefits. See Creating Calculation Scripts for Two-Pass and Intelligent Calculation.
Use a calculation script instead of the two-pass tag to ensure efficient use of Intelligent Calculation. See Understanding the Interaction of Two-Pass Calculation and Intelligent Calculation.
You must use a calculation script to calculate a formula twice if the database configuration means that Essbase uses Scenario A, as described in Scenario A, and if the formula references values from another data block.
You may want to use a calculation script to calculate two-pass formulas if the database configuration means that Essbase uses Scenario B, as described in Scenario B.
A database setting enables two-pass calculation in default calculations. When you perform a default calculation on a database with two-pass calculation enabled (the default setting), Essbase automatically attempts to calculate formulas tagged as two-pass in the dimension tagged as accounts in the database outline. This is true even if you have customized the default calculation script.
To perform a default calculation, use a tool:
Before the calculation script command that recalculates a two-pass formula, add the SET UPDATECALC OFF command to disable Intelligent Calculation. If you have Intelligent Calculation enabled (the default), Essbase calculates only the data blocks that are not marked as clean, but when you perform a default calculation of the database with Intelligent Calculation enabled, all data blocks are marked as clean, so Essbase does not perform the two-pass formula recalculation.
If you have changed the default calculation of CALC ALL, and Intelligent Calculation is enabled, the data blocks may not be marked as clean after the first calculation. See Understanding Intelligent Calculation.
To obtain the performance benefits of Intelligent Calculation when performing the first, full calculation of the database, use one of these methods, depending on the calculation needs and outline structure:
The outline has a dimension tagged as accounts, and it is a dense dimension. You want to calculate sales for each product as a percentage of sales for all products. Assume this formula should calculate the dimension:
Sales % Sales -> Product
When Essbase calculates the data block for each product, it has not yet calculated the value Sales -> Product, so the results for the sales of each product as a percentage of total sales are incorrect.
Mark the recalculated blocks as clean, even though this calculation is a partial calculation of the database. If you do not use the command SET CLEARUPDATESTATUS AFTER, Essbase marks data blocks as clean only after a full calculation of the database.
SET UPDATECALC ON; CALC ALL; SET UPDATECALC OFF; SET CLEARUPDATESTATUS AFTER; "Share of Sales" = Sales % Sales -> Product;
To tag a member as two-pass, and use a calculation script to calculate first the full database, then the two-pass member:
SET UPDATECALC ON; CALC ALL; SET UPDATECALC OFF; SET CLEARUPDATESTATUS AFTER; CALC TWOPASS;
To perform a default calculation from a client and then use a calculation script to perform the formula calculation:
Perform a full calculation, using any of the tools listed in Table 179, Methods for Performing a Full Calculation .
SET UPDATECALC OFF; SET CLEARUPDATESTATUS AFTER; "Share of Sales" = Sales % Sales -> Product;
SET UPDATECALC OFF; SET CLEARUPDATESTATUS AFTER; CALC TWOPASS;
SET CLEARUPDATESTATUS OFF; CALC ALL; CALC TWOPASS; SET CLEARUPDATESTATUS ONLY; CALC ALL;
The SET CLEARUPDATESTATUS OFF command tells Essbase not to mark the calculated data blocks as clean.
The first CALC ALL command causes Essbase to cycle through the database, calculating all dirty data blocks. Essbase does not mark the calculated data blocks as clean. Essbase does not automatically recalculate the formulas tagged as two-pass in the database outline.
The CALC TWOPASS command causes Essbase to cycle through the database, recalculating the formulas that are tagged as two-pass in the dimension tagged as accounts in the database outline. Essbase recalculates the formulas because the required data blocks are not marked as clean by the previous CALC ALL. Essbase does not mark the recalculated data blocks as clean.
The last CALC ALL command causes Essbase to cycle through the database and mark all the data blocks as clean. Essbase searches the index and marks the data blocks as clean. It does not calculate the data blocks.
Queries and calculations that reference a member that has been tagged as Dynamic Calc or Dynamic Calc and Store may be significantly slower than queries and calculations involving the same members, if the member has formulas involving any of these functions:
Table 180 shows how Essbase calculates #MISSING values. In this table, X represents any number:
Table 180. How Essbase Treats #MISSING Values
X + #MISSING
X – #MISSING
#MISSING – X
X * #MISSING
X / #MISSING
#MISSING / X
X / 0
X % #MISSING
#MISSING % X
X % 0
X == #MISSING
FALSE, unless X is #MISSING
X != #MISSING
X < > #MISSING
TRUE, unless X is #MISSING
TRUE, unless X is #MISSING
X <= #MISSING
(X <= 0)
X >= #MISSING
(X >= 0) or (X == #MISSING)
X > #MISSING
(X > 0)
X < #MISSING
(X < 0)
X AND #MISSING:
Y AND #MISSING, where Y represents any nonzero value
0 AND #MISSING
#MISSING AND #MISSING
X OR #MISSING:
Y OR #MISSING, where Y represents any nonzero value
0 OR #MISSING
#MISSING OR #MISSING
#MISSING for any Essbase function of one variable
#MISSING for any X not in the domain of f and any EssbaseEssbase function of multiple variables (except where specifically noted)
By default, Essbase does not roll up #MISSING values. However, if you always load data at level 0 and never at parent levels, you should enable the setting for consolidating #MISSING values. This setting provides a calculation performance improvement of 1%–30%. The performance improvement varies, depending on database size and configuration.
The default, not consolidating #MISSING values, must be in effect if you load data at parent, rather than child, levels, if any child member combinations have #MISSING values. If all child member combinations have any other values, including zero (0), Essbase rolls up the child values and overwrites the parent values correctly, so you can safely change the default.
To consolidate, enable the setting for consolidating #MISSING values by using one of the methods described above. The degree of performance improvement you achieve depends on the ratio between upper-level blocks and input blocks in the database.
To change how Essbase consolidates #MISSING values, use a tool:
If you enable the setting for consolidating #MISSING values, the cell calculation order within a data block changes. See Cell Calculation Order.
For a information on how Essbase calculates #MISSING values, see Consolidating #MISSING Values.
Removing empty blocks improves performance when data values already have been loaded. However, data load process time increases if new values require that blocks be created.
In Dynamically Calculating Data Values, see the following topics:
In Developing Calculation Scripts for Block Storage Databases, see the following topics:
When you convert currencies using the CCONV command, the resulting data blocks are marked as dirty for the purposes of Intelligent Calculation. This means that Essbase recalculates all the converted blocks when you recalculate the database. See Understanding Intelligent Calculation.