Essbase Types of Restructures
Essbase Types of Restructures
Essbase Types of Restructures
Changes to an Essbase outline cause changes to the Essbase index and data files, regardless of the
method (Essbase Administration Services, Hyperion Planning database refreshes, or from a script).
Changes that require restructuring the database are time-consuming (unless data is discarded before
restructuring). Understanding the types of restructures and what causes them can help database
owners more effectively manage the impacts to users.
TYPES OF RESTRUCTURES
Essbase initiates an implicit restructure after an outline is changed, whether done with the outline
editor, through an automated build, or some other fashion like a Hyperion Planning database refresh.
The type of restructure that is performed depends on the type of changes made to the outline.
Sparse restructures are typically fast, but depend on the size of the index file(s). Sparse restructures
are faster than dense restructures.
OUTLINE ONLY: If a change affects only the database outline, Essbase does not restructure the index
or data files. Member name changes, creation of aliases, and dynamic calculation formula changes are
examples of changes that affect only the database outline.
When a restructure occurs, every block that is impacted is tagged as dirty. If Intelligent Calculations
are used in the environment, they don’t provide any value when a dense restructure occurs as all
blocks will be calculated. When member names or formulas are changed, the block is not tagged as
dirty.
The following outline changes will force a dense restructure, which is the most time- consuming
restructure.
SPARSE (INDEX)
NO RESTRUCTURE OCCURS
Understanding this can help users and administrators manage applications to better meet the needs of
all those involved. When designing an application, knowledge of this topic can be instrumental in the
success of the application. Here are some things to keep in mind.
When updating an outline or refreshing a planning application, it may be faster to export level 0 (or input
level) data, clear the data, perform the update, and reload/aggregate the export when changes cause a dense
restructure.
For dimensions that are updated frequently, it may be beneficial to define those dimensions as sparse.
Changes to sparse dimensions typically require only restructures to the index file(s), which are much faster.
If frequent changes are required, enabling incremental restructuring may make sense. Using this defers
dense restructures. The Essbase restructure happens on a block by block basis, and occurs the first time the data
block is used. The cost is that calculations will cause restructures for all the blocks included and the calculation
performance will degrade.
Setting the isolation level to committed access may increase memory and time requirements for database
restructure. Consider setting the isolation level to uncommitted access before a database restructure.
If multiple people have access to change the outline, outline logging may be useful. This can be turned
on by adding OUTLINECHANGELOG = TRUE in the essbase.cfg.
Monitoring progress of a restructure is possible when access to the server is granted. Both sparse and
dense restructures create temporary files that mirror the index and data files. Data exists in the .pag files while
indexes are stored in .ind files. As the restructure occurs, there are equivalent files for each (pan for data files
and inn for index files). In total, the restructure should decrease the size of the ind