Essbase Optimization
Essbase Optimization
Essbase Optimization
by
Amit Sharma
http://learnobiee.blogspot.com
mail to aloo_a2@yahoo.com
Index Cache
When you request a data block, the index is used to find its location on disk. If the block
location is not found in the index cache, the index page that has the block entry is pulled into
memory (into the index cache) from the disk. If the index cache is full, the least recently used
index page in memory (in the index cache) is dropped to make room for the new index page.
Index:
100-10, New York 11
Data Cache Data blocks can reside on physical disk and in RAM. The amount of
memory allocated for blocks is called the data cache.
When a block is requested, the data cache is searched. If the block is found in the data cache, it
is accessed immediately. If the block is not found in the data cache, the index is searched for the
appropriate block number. The block's index entry is then used to retrieve the block from the proper
data file on disk.
Calculator Cache The calculator cache is a buffer in memory that Essbase uses to create and
track data blocks during calculation operations. Essbase can create a bitmap,
whose size is controlled by the size of the calculator cache, to record and
track data blocks during a calculation. Determining which blocks exist using
the bitmap is faster than accessing the disk to obtain the information,
particularly if calculating a database for the first time or calculating a
database when the data is very sparse.
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). Essbase uses a separate dynamic calculator cache
for each open database. The DYNCALCCACHEMAXSIZE
setting in the essbase.cfg file specifies the maximum size of
each dynamic calculator cache on the server.
The average clustering ratio database statistic indicates the fragmentation level of the data (.pag) files. The
Minimize the number of dimensions. Do not ask for everything in one model
Minimize complexity of individual dimensions. Consider UDAs and Attribute Dimensions
in order to reduce the size of some of the dimensions
Examine the level of granularity in the dimensions.
Dense Largest Dense dimensions from largest to smallest. Small and large is measured
Smallest
simply by counting the number of Stored members in a dimension. The
effect of sparse dimension ordering is much greater than dense dimension
Sparse smallest ordering.
to Largest
Sparse dimensions from smallest to largest. This relates directly to how
the calculator cache functions.
Finding the optimal configuration for the Dense/sparse settings is the most
important step in tuning a database.
Optimize the block size. This varies per operating system, but in choosing the best
Dense/sparse configuration keep in mind that blocks over 100k tend to yield poorer
performance. In general, Analytic Services runs optimally with smaller block sizes
The actual cache settings recommended is strongly dependent on your specific situation.
To measure the effectiveness of the cache settings, keep track of the time taken to do a
calculation and examine the hit ratio statistics in your database information.
Increase the Retrieval Buffer size. This helps if retrievals are affected due to dynamic
calculations and attribute dimensions.
Increase the Retrieval Sort Buffer size if you are performing queries involving sorting or
ranking.
Smaller block sizes tend to give better retrieval performance. Logically, this makes sense
because it usually implies less I/O.
Smaller reports retrieve faster.
Attribute may impact the calculation performance which usually has a higher importance
from a performance standpoint.
If you have a lot of dynamic calculations or attribute dimensions
Higher Index cache settings may help performance since blocks are found quicker
Unary calculations are the fastest. Try to put everything in the outline and perform a Calc
All when possible.
You should FIX on sparse dimensions, IF on dense dimensions. FIX statements on sparse
dimensions only brings into memory blocks with those sparse combinations which the calc
has focused on. If statements on dense dimensions operate on blocks as they are brought
into memory.
Use the Two Pass Calculation tag. Try to avoid multiple passes on the database. In the
case where the calculation is a CALC
Use Intelligent Calc in the case of simple calc scripts.
Step 9: Defragmentation
Fragmentation occurs over time as data blocks are updated. As the data blocks are updated,
they grow (assuming you are using compression) and the updated blocks are appended to
the page file. This tends to leave small free space gaps in the page file.
Time - The longer you run your database without clearing and reloading the more likely it
is that it has become fragmented.
Incremental Loads - This usually leads to lots of updates for blocks.