Essbase Application Performance Tuning

Essbasse system and application performance tuning are very important tasks for a successful implementation of
Essbase or Hyperion Planning. Good application design and proper system administration include some of following
items.
1) Design The Outline Hour Glass Model
2) Defragmentation
3) Database Restructuring
4) Compression Techniques
5) Cache Settings
6) Intelligent Calculation
7) Data Load Optimization
8) Uncommitted Access
Design the Outline using Hour Glass Model:
We have to build the Outline should be in a way that dimensions are placed in the following order
1) Dimension tagged as an Account Dimension Type
2)Dimension tagged as a Time Dimension Type
3) Largest dense
4)Smallest dense
5) Smallest sparse
6) Largest sparse
Attribute Dimensions.
Using hourglass model improves the calculation Performance of the cube.
Defragmentation:
Fragmentation is caused by any of the following activities:
1) Frequent data loads
2) Frequent data retrieval
3) Calculations
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 Three ways of doing Defragmentation.
Export Data of the application in to text file, then clear data and reload the data using text file without using Rules file.
1)Using MAXL Command:
Alter Database App name .DB name Force Restructure;
2)Add and Delete One Dummy Member in the Dense Dimension to force a full restructure.
Database Restructuring:
There are 3 types of Restructure.
1)Outline Restructure
2)Sparse Restructure
3)Dense Restructure/Full Restructure

Outline Restructure:
When we rename any member or add Alias to any member or member formula changes then outline Restructure
would happen.
Dense Restructure:
If we want to moved, delete and add a member to a dense dimension then dense Restructure would happen.
Sparse Restructure:
when we moved, deleted, or added a member to a sparse dimension then sparse restructure would happen.
Compression Techniques:
There are 4 types of Compressions. They are
1)Bitmap Compression
2)RLE Run length Encoding
3)ZLIB
4)No Compression.
Index Cache: Min -1024 KB (1048576 bytes) Default Buffered I/O : 1024 KB (1048576 bytes);Direct I/O : 10240 KB
(10485760 bytes) Opt -Combined size of all essn.ind files, if possible; as large as possible otherwise. Do not set this
cache size higher than the total index size, as no performance improvement results.
Data File Cache:
Min Direct I/O: 10240 KB(10485760 bytes) Default -Direct I/O: 32768 KB(33554432 bytes) Opt -Combined size of
all essn.pag files, if possible; otherwise as large as possible. This cache setting not used if Essbase is set to use
buffered I/O.

Data Cache: Min 3072 KB (3145728 bytes) Default 3072 KB (3145728 bytes) Opt -0.125 * the value
of data file cache size.
Calculator Cache: Min 4 bytes Max: 200,000,000 bytes Default 200,000 bytes Opt -The best size for
the calculator cache depends on the number and density of the sparse dimensions in your outline. The
optimum size of the calculator cache depends on the amount of memory the system has available.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.
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;
Data Load Optimization:
Data load optimization can be achieved by the following.
1)Always load the data from the Server than file system.
2)The data should be at last after the combinations.
3)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) .Sorting data prior to loading in this manner will allow a block to be fully

populated prior to storing it on disk .thus eliminating the need to retrieve a previously created block from disk during
the load.
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 32-Bit 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 load.
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.

Fine tuning within an optimization of Hyperion Essbase

Fine tuning within an optimization of Hyperion Essbase can be accomplished by being very secure in using Essbase
member properties (like stored member, dynamic calculation member, label only, two pass calc etc).
Besides optimization tip 5, there are several aspects to be considered.

Try to avoid "dyna calc" at sparse dimensions

Use "Label only" as much as possible if data is not required to be stored
Use "dyna calc" at dense dimensions (you have to for ratios or percentages anyway)
Try to avoid dynamic calculations on a large span of data blocks
Try to avoid using "Two pass calc", it slows down significantly and there is no "Third pass calc"
This is a technical advice for Hyperion Essbase. However, never forget that the functional interpretation is the most
important: understand what the requirements of the client are. You can never come to powerfull solution if you didnt
understand what the functional needs and processes are. The technical aspects are just a matter of experience and
understanding how Essbase functions under the hood.
We have proved to be able to achieve optimizations up to 1000%. See a brief list of our achievements here.

Essbase Tuning For Planning Applications

Tuning Essbase for use with Planning in order to improve performance and avoid errors araising
from a lack of resources when running Business Rules and Calculation Scripts.
The Folling are basic guidelines for Essbase tuning that are intended to cover the use of Essabse
with Planning applications.

To Improve performance go through each of the suggested optimizations below and then test to see
where the most progress is made. Always remember to back up your Essabse data before making
any changes.
1. Block Size: The recommended block size is between 8Kb and 100Kb. the only wat to alter block
size is to change sparse dimensions to dense or vice versa. Changing a dense dimention to sparse
will reduce block size and increate the overall number of blocks. See the Planning documentation for
more information on setting dimensions to be dense or sparse.
2. Vertual Memory: Recommended virual memory setting for Window sytems: 2 to 3 times the RAM
Available. 1.5 times the RAM on older systems.
3. Chaches:
Index Cache:
Minimum: 1Mb
Default: 10 Mb
Recommended: combined size of all ESS*.IND files if possible;
otherwise as large as possible given the availbal RAM
DataFile Cache:
Minium: 8 Mb
Default: 32 Mb
Recommended: combined size of all ESS*.PAG files if possible;
Otherwise as large as possible given the available RAM, up to a maximum of 2GB.
Importent: The Data File Cache is not used if the database is buffered rather than direct I/O
(Check the "Storage" tab). Since all Planning databases are buffered, and most customers
use buffered for native Essbase apllications too, this cache setting is usually not relevant. the
Data Cache is the setting that matters in most cases.
Data Cache:
Miniumum: 3 Mb
Default: 3 Mb
Recommended: 0.125 * combined size of all ESS*.PAG files, if possible, otherwise as large as
possible given the available RAM.
Note: A useful indication of the health of the caches can be gained by looking at the "Hit
Ratio" for the cache on the Statistics tab in EAS. 1.0 is the best possible ratio, lower means
lower performance.
4. Disk Space: The recommended disk space is a minimum of double the combined total of all .IND
and .PAG files. You need double the space because you have to have room for a restructure, whcih
will require twice the usal storage space whilst it is ongoing.