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

1.3. 3. . Sparse Restructure: If a member of a sparse dimension is moved.OTL again. can take a long time to complete for large databases. Add and Delete One Dummy Member in the Dense Dimension . 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. Empty blocks are not removed.OTN which in turn converts in to . Essbase restructures the index and creates new index files. the most time-consuming of the restructures. They are 1. Compression Techniques: There are 4 types of Compressions. Dense Restructuring. . the time required depends on the index size. Essbase restructures the blocks in the data files and creates new data files. deleted.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. it regenerates the index automatically so that index entries point to the new data blocks. Restructuring the index is relatively fast. . or added. Bitmap Compression RLE – Run length Encoding ZLIB No Compression. Essbase marks all restructured blocks as dirty. Restructuring: There are 3 types of Restructure. 3. 2.OTL file is converted to . 4. When Essbase restructures the data blocks. so after a dense restructure you must recalculate the database. 2.

by default it is set to 3MB. 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 (.Caches: There are 5 types of caches. Set cache High|Low|Off. 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. Note: Restart the database in order to make the new cache settings come in to effect. 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. Size of the Data file cache should be size of the PAG File memory. 3. Data Cache: Data cache is a buffer in a memory that holds Uncompressed Data Blocks. Subsequently.IND).5% of the PAG file memory. Data cache should be 12. 1. -----à command used in calc scripts to set the cache. We set cache value for calculator cache in Essbase. for a query). Index cache should be set equal to the size of the index file. when we change value in any block the block is marked as Dirty . When we run Calc all/Calc dim Essbase would calculate and mark all blocks as Clean blocks. 2. WE set the calculator cache in calculation scripts. Data File Cache: Data file cache is a buffer in memory that holds Compressed data blocks. 4.cfg file. Intelligent Calculation: Whenever the Block is created for the 1st time Essbase would treat it as Dirty Block. Calculator Cache: It is basically used to improve the performance of calculation. It is set to 32MB by default. We need to restart the server to make the changes in calculator cache after setting it in config file. Max. 5.

The Essbase performance is better if we set uncommitted access. Always load the data from the Server than file system. blocks are released more frequently than with committed access. Essbase locks blocks for write access until Essbase finishes updating the block. Loads 4 records at a time for 32Bit system and 8 records for 64-Bit system. Besides. The data should be at last after the combinations. Restrict max Decimal Points to ‘3’ --à 1. 4. Uncommitted Access: Under uncommitted access. Always Pre-Aggregate data before loading data in to Database. 3. By default Intelligent calculation is ON. Data should be loaded in the form of Inverted Hourglass Model. .block. Under committed access. By default Essbase Loads data Record – by – Record which would consume more time resulting in consuming huge time for data loads. Essbase holds locks until a transaction completes. DL Threads write (4/8): Used for Parallel Data loads. With uncommitted access. Data Load Optimization: Data load optimization can be achieved by the following.(Largest sparse to Smallest Sparse followed by smallest Dense to Largest Dense data) 6. 1. when we run calc scripts again only dirty blocks are calculated it is known as Intelligent Calculation. Should use #MI instead of ‘0’s. 2. If we use ‘0’ uses 8 bytes of memory for each cell. in scripts . parallel calculation only works with uncommitted access.234 5. To turn off the Intelligent Calculation use command SET Update Calc OFF.