Designing for Calculation Performance You can configure a database to optimize calculation performance.

The best configuration for the site depends on the nature and size of the database. Use the information in the following topics as guidelines only: Block Size and Block Density Order of Sparse Dimensions Incremental Data Loading Database Outlines with Two or More Flat Dimensions Formulas and Calculation Scripts

Block Size and Block Density A data block size of 8Kb to 100Kb provides optimal performance in most cases. If data blocks are much smaller than 8Kb, the index is usually very large, forcing Analytic Services to write to and retrieve the index from disk. This process slows down calculation. If data blocks are much larger than 100Kb, Intelligent Calculation does not work effectively. To optimize calculation performance and data storage, you need to balance data block density and data block size. You can create balance by rearranging the dense and sparse dimension configuration of the database. Therefore, keep these suggestions in mind: Keep data block size between 8 Kb and 100 Kb with as high a block density as possible. Run test calculations of the most promising configurations of a database that contains representative data. Check the results to determine the configuration that produces the best calculation performance.

You can view information about a database, including the potential and actual number of data blocks and the data block size. To view data block information, use either of the following methods: Tool Administration Services ESSCMD Topic Checking Data Block Statistics GETDBINFO Location Essbase Administration Services Online Help Technical Reference

Order of Sparse Dimensions 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 a number of 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 very large dimension (for example, a dimension containing 1000 members). Parallel calculation, if enabled, is more likely to be used if the standard sparse dimension with the most members is the last standard sparse dimension in the outline.

Incremental Data Loading Many companies load data incrementally. For example, a company may load data each month for that month. 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, Analytic Services 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 are updated. The data blocks for January and February do not change. With Intelligent Calculation enabled, Analytic Services recalculates only the data blocks for March and the dependent parents of March. 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, Analytic Services recalculates only the blocks affected by the partial load, even though time is dense and Intelligent Calculation is enabled. Database Outlines with Two or More Flat Dimensions

Calculation performance may be affected if a database outline has two or more 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 can improve performance for outlines with two or more flat dimensions by adding intermediate levels to the database outline. Formulas and Calculation Scripts 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 Analytic Services 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. Monitoring and Tracing Calculations You can display information in the application log about how Analytic Services is calculating the database by using the following commands in a calculation script: SET MSG SUMMARY and SET MSG DETAIL SET NOTICE

SET MSG SUMMARY and SET MSG DETAIL You can use the SET MSG SUMMARY and SET MSG DETAIL calculation commands in a calculation script to do the following: Display calculation settings, for example, whether completion notice messages are enabled Provide statistics on the number of data blocks created, read, and written Provide statistics on the number of data cells calculated

The SET MSG DETAIL command also provides a detailed information message every time Analytic Services calculates a data block. SET MSG DETAIL is useful for reviewing the calculation order of data blocks and for testing intelligent recalculations. Caution Because the SET MSG DETAIL command causes a high processing overhead, ! use it only during test calculations.

SET MSG SUMMARY causes a processing overhead of approximately 1% to 5%, depending on database size, and is therefore appropriate for all calculations. SET NOTICE 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. Using Simulated Calculations to Estimate Calculation Time 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 like 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 timestamped at 09:50:10 AM, and the second is time-stamped at 09:50:20 AM, you know that each of part of the calculation took ten 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 will also take 30 seconds. If there were only two messages total, then you would know that the real calculation will take approximately 60 seconds (20 /10 * 30 = 60 seconds). Parallel Calculation Guidelines Outline structure and application design determine whether enabling parallel calculation can improve calculation performance. Before you enable parallel calculation, review the following guidelines. If you do not adhere to the guidelines, you may not receive the full benefit of parallel calculation: Use the uncommitted access isolation level. Parallel calculation is not supported if you use the committed access isolation level. One or more formulas present in a calculation may prevent Essbase from using parallel calculation even if it is enabled. Calculation tasks are usually generated along the last sparse dimension of an outline. Order the sparse dimensions in an outline from smallest to

largest, based on actual size of the dimension as reported by the ESSCMD command GETDBSTATS. This ordering recommendation is consistent with recommendations for optimizing calculator cache size and consistent with other outline recommendations. For a description of situations that may need to use additional dimensions (more than the last sparse dimension) and for instructions on how to increase the number of sparse dimensions used. Parallel calculation is effective on non-partitioned applications and these partitioned applications: Replicated partitions Linked partitions Transparent partitions if the calculation occurs at the target database. The number of sparse dimensions specified by CALCTASKDIMS in the essbase.cfg file or by SET CALCTASKDIMS in a calculation script must be set at 1 (the default value).

If you have selected incremental restructuring for a database and you have made outline changes that are pending a restructure, do not use parallel calculation. Unpredictable results may occur.

Relationship between Parallel Calculation and Other Analytic Services Features The following topics discuss the relationship between parallel calculation and other Analytic Services functionality: Retrieval Performance Placing the largest sparse dimension at the end of the outline for maximum parallel calculation performance may slow retrieval performance.

Formula Limitations The presence of some formulas may force serial calculation. The following formula placements are likely to force serial calculation: A formula on a dense member, including all stored members and any Dynamic Calc members upon which a stored member may be dependent, which causes a dependence on a member of the dimension that is used to identify tasks for parallel calculation. A formula that contains references to variables declared in a calculation

script that uses @VAR, @ARRAY, or @XREF. A member formula that causes a circular dependence. For example, member A has a formula referring to member B, and member B has a formula referring to member C, and member C has a formula referring to member A. A formula on a dense or sparse member with a dependency on a member or members from the dimension used to identify tasks for parallel processing.

If you need to use a formula that might prevent parallel calculation, you can either mark the member of the formula as Dynamic Calc or exclude it from the scope of the calculation. To check if a formula is preventing parallel calculation, check the application log. Calculator Cache At the start of a calculation pass, Analytic Services checks the calculator cache size and the degree of parallelism and then uses the calculator cache bitmap option appropriate for maximum performance. Therefore, the bitmap option used for parallel calculation may be different from the one used for serial calculation. For example, assume Essbase performs a serial calculation and uses multiple bitmaps and a single anchoring dimension. Without explicit change of the calculator cache size, Analytic Services might perform a parallel calculation might using only a single bitmap and a single anchoring dimension. You can determine the calculator cache mode that controls the bitmap options by checking the application log at the start of each calculation pass for an entry similar to the following: Multiple bitmap mode calculator cache memory usage has a limit of [50000] bitmaps. When using parallel calculation in multiple bitmap mode, you may encounter high memory usage. If you encounter this situation, you can use the configuration setting PARCALCMULTIPLEBITMAPMEMOPT to optimize memory use in multiple bitmap mode. This setting can be used together with, or separately from, MULTIPLEBITMAPMEMCHECK. To enable PARCALCMULTIPLEBITMAPMEMOPT, add this line to your essbase.cfg file: PARCALCMULTIPLEBITMAPMEMOPT TRUE Transparent Partition Limitations Parallel calculation with transparent partitions has the following limitations: You cannot use parallel calculation across transparent partitions unless

the calculation occurs at the target. You must set CALCTASKDIMS or SET CALCTASKDIMS to 1 (the default) so that there is only one anchoring dimension. You must increase the calculator cache so that multiple bitmaps can be used. You can identify the calculator cache mode that controls the bitmap options by checking the application log at the start of each calculation pass for an entry similar to the following:

Multiple bitmap mode calculator cache memory usage has a limit of [50000] bitmaps. Restructuring Limitation Do not use parallel calculation if you have selected incremental restructuring. Parallel calculation does not support incremental restructuring.

Commit Threshold Adjustments Essbase checks the commit threshold specified by the database setting "Number of blocks before internal commit." If the setting requires less than 10 MB of data be written before an internal commit, then Essbase automatically increases the commit threshold for the duration of the calculation pass to 10 MB. If the setting is greater than 10 MB, Analytic Services uses the setting value. Analytic Services writes a message to the application log noting the temporary increase if it occurs. If you can allocate more than 10 MB extra disk space for calculation, consider increasing the commit threshold value, that is, the number of blocks before a commit, to a very large number for better performance. To view the current threshold, use any of the following methods: Tool Administration Services MaxL ESSCMD Topic Setting Data Integrity Options display database dbs_name GETDBINFO: Number of blocks modified before internal commit Location Essbase Administration Services Online Help Technical Reference Technical Reference

To modify the commit threshold, use any of the following methods:

Tool Administration Services MaxL

Topic Setting Data Integrity Options

Location Essbase Administration Services Online Help

alter database dbs_name Technical Reference, list of set implicit_commit after n MaxL statements blocks SETDBSTATEITEM 21 Example of Specifying Isolation Level Settings with ESSCMD

ESSCMD

Isolation Level Limitation You must use uncommitted mode for parallel calculation. To set the isolation level to uncommitted mode, use any of the following methods: Tool Administration Services MaxL ESSCMD Topic Location

Setting Data Integrity Options Essbase Administration Services Online Help alter database dbs_name Technical Reference, list of disable committed_mode MaxL statements SETDBSTATEITEM 18 Example of Specifying Isolation Level Settings with ESSCMD

Optimizing Calculation and Retrieval Performance To optimize attribute calculation and retrieval performance, consider the following considerations: The calculation order for attribute calculations is the same as the order for dynamic calculations.

Since Analytic Services calculates attribute data dynamically at retrieval time, attribute calculations do not affect the performance of the overall (batch) database calculation. Tagging base-dimension members as Dynamic Calc may increase retrieval time. When a query includes the Sum member and an attribute-dimension member whose associated base-member is tagged as two-pass, retrieval time may be slow.

To maximize attribute retrieval performance, use any of the following techniques: 1. Configure the outline using the tips. 2. Drill down to the lowest level of base dimensions before retrieving data. For example, in Spreadsheet Add-in, turn on the Navigate Without Data feature, drill down to the lowest level of the base dimensions included in the report, and then retrieve data. 3. When the members of a base dimension are associated with several attribute dimensions, consider grouping the members of the base dimension according to their attributes. For example, in the Sample Basic database, you could group all 8-ounce products. Grouping members by attribute may decrease retrieval time.