Hyperion

OPTIMIZATION IN ESSBASE: Application Performance Optimization can be done by the following techniques 1. 2. 3. 4. 5. 6. 7. 8. Designing of The Outline using Hour Glass Model Defragmentation Restructuring Compression Techniques Cache Settings Intelligent Calculation Uncommitted Access Data Load Optimization

Designing of The Outline using Hour Glass Model: Outline should be designed in such a way that dimensions are placed in the following order - largest dense to smallest dense, smallest sparse to largest sparse followed by Attribute Dimensions. Using hourglass model improves 10% of calculation Performance of the cube. Defragmentation: Fragmentation is caused due to the following 1. 2. 3. Frequent Data Load Frequent Retrieval Frequent Calculation

We can check whether the cube is fragmented or not by seeing its Average Clustering Ratio in the properties . The Optimum clustering value is 1, If the average clustering ratio is less than 1, then the cube is fragmented which degrades the performance of the cube. There are 3 ways of doing Defragmentation: 1. Export Data of the application in to text file, then clear data and reload the data using text file without using Rules file. 2. Using MAXL Command:

Maxl>Alter Database Appname.DB name Force Restructure

3.

Add and Delete One Dummy Member in the Dense Dimension .

Restructuring: There are 3 types of Restructure. 1. 2. 3. Outline Restructure Sparse Restructure Dense Restructure/Full Restructure

Outline Restructure: When we rename any member or add Alias to any member then outline Restructure would Happen. .OTL file is converted to .OTN which in turn converts in to .OTL again. .OTN file is a temp file deleted by default after restructure Dense Restructure(Full Restructure): If a member of a dense dimension is moved, deleted, or added, Essbase restructures the blocks in the data files and creates new data files. When Essbase restructures the data blocks, it regenerates the index automatically so that index entries point to the new data blocks. Empty blocks are not removed. Essbase marks all restructured blocks as dirty, so after a dense restructure you must recalculate the database. Dense Restructuring, the most time-consuming of the restructures, can take a long time to complete for large databases.

Sparse Restructure: If a member of a sparse dimension is moved, deleted, or added, Essbase restructures the index and creates new index files. Restructuring the index is relatively fast; the time required depends on the index size.

Compression Techniques: There are 4 types of Compressions. They are 1. 2. 3. 4. Bitmap Compression RLE Run length Encoding ZLIB No Compression.

Caches: There are 5 types of caches. 1. 2. 3. 4. 5. Index cache Data Cache Data File Cache Calculator Cache Dynamic Calculator Cache

Index Cache: Index Cache is a buffer in a memory that holds Index Files (.IND). Index cache should be set equal to the size of the index file. Note: Restart the database in order to make the new cache settings come in to effect. Data Cache: Data cache is a buffer in a memory that holds Uncompressed Data Blocks. Data cache should be 12.5% of the PAG file memory, by default it is set to 3MB. Data File Cache: Data file cache is a buffer in memory that holds Compressed data blocks. Size of the Data file cache should be size of the PAG File memory. It is set to 32MB by default. Max. Size for data file cache is is 2GB We can use only either Data cache/ Data file cache most of the developers prefer Data cache in Real time. Calculator Cache: It is basically used to improve the performance of calculation. WE set the calculator cache in calculation scripts. Set cache High|Low|Off; ----- command used in calc scripts to set the cache. We set cache value for calculator cache in Essbase.cfg file. We need to restart the server to make the changes in calculator cache after setting it in config file. Dynamic Calculator Cache: The dynamic calculator cache is a buffer in memory that Essbase uses to store all of the blocks needed for a calculation of a Dynamic Calc member in a dense dimension (for example, for a query). Intelligent Calculation: Whenever the Block is created for the 1st time Essbase would treat it as Dirty Block. When we run Calc all/Calc dim Essbase would calculate and mark all blocks as Clean blocks. Subsequently, when we change value in any block the block is marked as Dirty

block. when we run calc scripts again only dirty blocks are calculated it is known as Intelligent Calculation. By default Intelligent calculation is ON. To turn off the Intelligent Calculation use command SET Update Calc OFF; in scripts .

Uncommitted Access: Under uncommitted access, Essbase locks blocks for write access until Essbase finishes updating the block. Under committed access, Essbase holds locks until a transaction completes. With uncommitted access, blocks are released more frequently than with committed access. The Essbase performance is better if we set uncommitted access. Besides, parallel calculation only works with uncommitted access.

Data Load Optimization: Data load optimization can be achieved by the following. 1. 2. 3. Always load the data from the Server than file system. The data should be at last after the combinations. Should use #MI instead of 0s. If we use 0 uses 8 bytes of memory for each cell.

4. Restrict max Decimal Points to 3 -- 1.234 5. Data should be loaded in the form of Inverted Hourglass Model.(Largest sparse to Smallest Sparse followed by smallest Dense to Largest Dense data) 6. Always Pre-Aggregate data before loading data in to Database.

DL Threads write (4/8): Used for Parallel Data loads. Loads 4 records at a time for 32Bit system and 8 records for 64-Bit system. By default Essbase Loads data Record by Record which would consume more time resulting in consuming huge time for data loads.