Essbase Types of Restructures

Download as docx, pdf, or txt
Download as docx, pdf, or txt
You are on page 1of 3

Essbase Database Restructures

2011Posted by Kyle Goodfriend |       In: Hyperion Essbase · Hyperion Planning · Performance · Product Overview


Printer Friendly

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.

DENSE 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.

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.

Outline restructures are very quick and typically take seconds.


Explicit restructures occur when a user requests a restructure to occur.  This can be done in Essbase
Administration Services or via Maxl (and EssCmd for those of you who still use it) and forces a full
restructure (see dense restructure above).  It is worth noting that this also removes empty blocks.

CALCULATING IMPLICATIONS AFTER RESTRUCTURES

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.

WHAT DICTATES THE RESTRUCTURE TYPE

The following outline changes will force a dense restructure, which is the most time- consuming
restructure.

DENSE AND SPARSE

 Defining a regular dense dimension member as dynamic calc


 Defining a sparse dimension regular member as dynamic calc or dynamic calc and store
 Defining a dense dimension dynamic calc member as regular member
 Adding, deleting, or moving dense dimension dynamic calc and store members
 Changing dense-sparse properties [Calc Required]
 Changing a label only property [Calc Required]
 Changing a shared member property [Calc Required]
 Changing the order of dimensions [Calc Required]

DENSE (DATA FILES)

 Deleting members from a dense dimension  [Calc Required]


 Adding members to a dense dimension
 Defining a dense dynamic calc member as dynamic calc and store member

SPARSE (INDEX)

 Adding members to a sparse dimension


 Moving members (excluding shared members) in a sparse dimension
 Defining a dense dynamic calc member as dynamic calc and store
 Adding, deleting, or moving a sparse dimension dynamic calc member
 Adding, deleting, or moving a sparse dimension dynamic calc and store member
 Adding, deleting, or moving a dense dimension dynamic calc member
 Changing the order of two sparse dimensions

NO RESTRUCTURE OCCURS

 Deleting members of a sparse dimension [Calc Required]


 Deleting members of an attribute dimension
 Deleting shared members from a sparse or dense dimension [Calc Required]
 Adding members to an attribute dimension
 Adding shared members to a sparse or dense dimension
 Moving a member in an attribute dimension
 Renaming a member
 Changing a member formula [Calc Required]
 Defining a sparse dynamic calc member as dynamic calc and store member
 Defining a dense or sparse dynamic calc and store member as dynamic calc
 Defining a regular dense dimension member as dynamic calc and store
 Defining a sparse dimension dynamic calc and store member or dynamic calc member as regular member
 Defining a dense dimension dynamic calc and store member as regular member
 Changing properties other than dense-sparse, label, or shared [Calc Required]
 Changing the order of an attribute dimension
 Creating, deleting, clearing, renaming, or coping an alias table
 Importing an alias table
 Setting a member alias
 Changing the case-sensitive setting
 Naming a level or generation
 Creating, changing, or deleting a UDA

WHAT DOES THIS MEAN

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 

You might also like