Introducing the Hyperion Essbase Kernel

This chapter describes how Hyperion Essbase accesses and stores data.

This chapter contains the following sections:

About the Hyperion Essbase Kernel

The Hyperion Essbase kernel provides the foundation for a variety of functions of the Hyperion Essbase server. These functions include data loading, calculations, spreadsheet lock&send, partitioning, and restructuring. The Hyperion Essbase kernel reads, caches, and writes data; manages transactions; and enforces transaction semantics to ensure data consistency and data integrity.

The Hyperion Essbase kernel has the following functions:

Handles disk storage and caching of Hyperion Essbase files
Handles data retrieval
Handles data updates
Controls input-output functions related to Hyperion Essbase
Consolidates free space for re-use
Manages concurrent operations
Recovers databases after a server crash
Issues locks
Manages transactions

The Hyperion Essbase kernel uses direct I/O (input/output) and no-wait I/O on most server platforms and file systems (for a list of the supported platforms, see the Hyperion Essbase Installation Guide). This means that Hyperion Essbase caches index and data files (.IND and .PAG files) directly and is able to perform asynchronous, overlapped I/Os. The following benefits are provided:

Faster response time. A user waits less time for Hyperion Essbase to return data.
Scalability and predictability. You determine the optimal cache sizes for Hyperion Essbase databases.

The Hyperion Essbase kernel contains components that control all aspects of retrieving and storing data. The following table summarizes the functions of these components:

*Table 42-1: Hyperion Essbase Kernel Components*
Component	Main Function
Index Manager	Find and track the location of requested data
Data Block Manager	Retrieves the data pointed to by the index and stores the data
LRO Manager	Handles retrieval and storage of linked reporting objects (LROs)
Lock Manager	Handles the locking of data blocks to regulate concurrent data access
Transaction Manager	Tracks transactions and handles internal commit and abort operations

For information on how the client communicates with the server, see Running Hyperion Essbase, Applications, and Databases.

Index Manager

The Index Manager manages the database index and provides a fast way of looking up Hyperion Essbase data blocks. The Index Manager manages the index cache and determines which portions of the database index are to be cached in the index cache.

The Index Manager controls five components. The following table summarizes the functions of these components:


Component	Main Function
Index	Contains all index files.
Index File	Stores retrieval information in index pages. Hyperion Essbase names index files incrementally on each disk volume, using the naming convention ESSxxxxx.IND, where xxxxx is a number. The first index file on each disk volume is named ESS00001.IND.
Index page	Holds index entries that point to data blocks.
Index entry	Points to a data block. An index entry exists for every intersection of sparse dimensions.
Index cache	Holds multiple index pages in memory.

The term index refers to all index files for a single database. The index can span multiple volumes, and more than one index file can reside on a single volume. Use the disk volumes setting to specify disk spanning parameters. See Specifying Hyperion Essbase Kernel Settings for information on setting index cache size and index page size and for information on allocating space with the disk volumes setting.

Allocation Manager

The Allocation Manager is part of the Index Manager. The Allocation Manager manages:

Creation and extension of index and data files on disk
File open and close operations
Designation of which volume to use for a new file
Sequence of volume use

The Allocation Manager bases space allocations on the disk volumes setting. You can specify disk volumes in Hyperion Essbase Application Manager or with MaxL or ESSCMD. See Specifying Hyperion Essbase Kernel Settings for information on the disk volumes setting.

The Allocation Manager makes decisions about when and where to create a new file. When additional data needs to be stored, the Allocation Manager proceeds as follows:

It attempts to use free space in an existing file.
If enough free space is not available, it attempts to expand an existing file.
If enough free space is not available in existing files, it creates a new file on the current volume.
If it cannot expand an existing file or create a new file on the specified volume, it attempts to use the next specified volume.
If all specified volumes are full, an error message is displayed, and the transaction is aborted.

Data Block Manager

The Data Block Manager brings data blocks into memory, writes them out to data files, handles data compression, and writes data files to disk. The Data Block Manager controls four components. The following table describes the functions of these components:


Component	Main Function
Data file	Stores retrieval information in data blocks. Hyperion Essbase names data files incrementally: ESSxxxxx.PAG, where xxxxx is a number starting with 00001.
Data block	A multidimensional array that represents cells of the dense dimensions for a given intersection of sparse dimensions.
Data cache	Holds data blocks in memory.
Data file cache	Holds data files in memory.

The size of the data file cache determines how much of the data within the data files can fit into memory at one time. The data cache size and the data block size determine how many data blocks can fit into memory at one time. Data files for a single database can span multiple volumes; more than one database can reside on the same volume. See Specifying Hyperion Essbase Kernel Settings for information on specifying data file cache size and data cache size and on allocating disk space.

LRO Manager

Linked reporting objects (LROs) enable you to associate objects, such as flat files, with data cells.

The Hyperion Essbase kernel stores information about linked reporting objects in an LRO catalog. Each catalog resides in its own Hyperion Essbase index page and coexists in an index file (ESSxxxxx.IND) with other, non-LRO Hyperion Essbase index pages. Users can create and store LRO files, with an.LRO extension, in the database directory (\ESSBASE\applicationname\databasename, for example, ESSBASE\SAMPLE\BASIC).

For more information about linked reporting objects, see Linking Objects to Hyperion Essbase Data and the Hyperion Essbase Spreadsheet Add-in User's Guide.

Lock Manager

The Lock Manager issues locks on data blocks and controls concurrent access to data. The committed access and uncommitted access isolation levels use different locking schemes. For more information on isolation levels and locking, see Ensuring Data Integrity.

Transaction Manager

The Transaction Manager controls transactions and commit operations and manages database recovery.

Hyperion Essbase commits data automatically. Commits are triggered by transactions that modify data: data loading, calculating, restructuring, and spreadsheet lock&send operations.

How Hyperion Essbase commits data depends upon whether the transaction isolation level is set to committed or uncommitted access (the default). See Specifying Hyperion Essbase Kernel Settings for information on specifying isolation level.

The Transaction Manager maintains a transaction control table, dbname.TCT, to track transactions.

See Ensuring Data Integrity for more information on commit operations and recovery.

Hyperion Essbase Kernel Startup

This section provides a summarized, high-level list of the steps that lead to Hyperion Essbase kernel start-up.

A user starts a database.
Hyperion Essbase loads the database.
The Hyperion Essbase Agent passes database settings to the server.
The Hyperion Essbase kernel begins its initialization process.
The Hyperion Essbase kernel starts its components: the Index Manager, Lock Manager, LRO Manager, Data Block Manager, and Transaction Manager.

If it encounters an error during start up, the Hyperion Essbase kernel shuts itself down.

Fatal Error Handling

When the Hyperion Essbase kernel encounters a fatal error, it shuts down and restarts, attempting to reinitialize itself and proceed with database recovery. When recovery begins, Hyperion Essbase displays an error message similar to the following:

"Reinitializing the Hyperion Essbase kernel due to a fatal error."

This message is followed by other informational messages related to database recovery, such as the following:

"Invalid transaction handle passed to the Hyperion Essbase kernel."

When you see these messages, you know that the Hyperion Essbase kernel shut itself down and is attempting to start up. Check the server log and determine whether Hyperion Essbase issued a fatal error message just before generating the reinitialization messages. See Using Diagnostics to Monitor Performance for information about the server log. See Rolling Back Transactions for more information about recovering transactions.

If the Hyperion Essbase kernel did encounter a fatal error, in most cases you need to reinitiate any operation that was active at the time of the fatal error. If the operation was a calculation or a data load, you may be able to continue where the operation left off; check the server log to see how far Hyperion Essbase processed the operation. When in doubt, reinitiate the operation.

If the Hyperion Essbase kernel did not encounter a fatal error, contact your software provider's technical support to determine what caused the Hyperion Essbase kernel to shut down and restart.

The Hyperion Essbase kernel considers the following errors fatal:

One or more control fields have unexpected or inconsistent values.
The Hyperion Essbase kernel detects data corruption.
The Hyperion Essbase kernel cannot perform an operation that is necessary to ensure data integrity (for example, disk space is insufficient).
The Hyperion Essbase kernel encounters a condition that can lead to data corruption.

Data Compression

A data compression setting determines whether Hyperion Essbase compresses data blocks when it writes them out to disk. Hyperion Essbase fully expands the compressed data blocks, including empty cells, when the blocks are swapped into the data cache. Data compression is enabled by default. Generally, data compression optimizes storage use.

There are two types of data compression: bitmap and run-length encoding (RLE).

Using Bitmap Data Compression

With bitmap compression, Hyperion Essbase uses a bitmap to represent data cells, and stores only the bitmap, the block header, and the other control information. A bitmap uses one bit for each cell in the data block, whether the cell value is missing or non-missing. When a data block is not compressed, Hyperion Essbase uses eight bytes to store every non-missing cell.

When using bitmap compression, Hyperion Essbase stores only non-missing values and does not compress repetitive values or zeros (contrast with RLE compression, described in Using RLE Data Compression). When Hyperion Essbase pages a data block into the data cache, it fully expands the data block, using the bitmap to recreate the missing values.

Because the bitmap uses one bit for each cell in the data block, the bitmap scheme provides a fixed overhead for data compression. Figure 42-1 represents a portion of a data block, as an example. In this example, Hyperion Essbase uses 64 bytes to store the data in the fully expanded block, but uses one byte (eight bits) to store the bitmap of the compressed data on disk. (Hyperion Essbase also uses a 72-byte block header for each block, whether the block is compressed or not.)

Figure 42-1: Bitmap Data Compression

Using RLE Data Compression

When using the run-length encoding (RLE) compression scheme, Hyperion Essbase compresses any consecutive, repetitive values--any value that repeats three or more times consecutively, including zero. Hyperion Essbase keeps track of each repeating value and the number of times it is repeated consecutively.

In the example in Figure 42-2, Hyperion Essbase uses 64 bytes to store the data in the fully expanded block, but uses 56 bytes to store the compressed data on disk. (Hyperion Essbase also uses a 72-byte block header for each block, whether the block is compressed or not.)

Figure 42-2: RLE Data Compression

Deciding Which Type of Compression to Use

In most cases, bitmap compression conserves disk space more efficiently. However, much depends on the configuration of the data.

The RLE compression type may be preferable under the following circumstances:

The average block density in the database is very low (three percent or lower).
The database has many consecutive zero values or any other consecutive, repeating value.

Deciding When to Disable Data Compression

You may want to disable data compression if blocks have very high density (90% or greater) and few consecutive, repeating data values. Under these conditions, enabling compression consumes resources unnecessarily.

Changing Data Compression Settings

Data compression is enabled by default. To change this option from Hyperion Essbase Application Manager, select Database > Settings, click the Storage tab, and select an option from the Data Compression list box. The options are Bitmap (the default), RLE, and No Compression.

You can also use alter database in MaxL or the SETDBSTATEITEM and SETDBSTATE commands in ESSCMD to change data compression settings. For more information, see the online Technical Reference in the DOCS directory.

When you change the data compression type, Hyperion Essbase uses the new option when it writes out data blocks to the database. Changing the compression type has no effect on blocks already on disk (until they are accessed, updated, and written out again).

See Specifying Data Compression for information on changing data compression settings.

Checking the Compression Ratio

The compression ratio represents the ratio of the compressed block size (including overhead) to the expanded block size, regardless of the compression type in effect. To check the compression ratio, select Database > Information in Hyperion Essbase Application Manager and click the Statistics tab or issue GETDBSTATS in ESSCMD.

Note:

The compression ratio can vary widely from block to block.

Data Compression

Because Hyperion Essbase compresses data blocks as they are written to disk, it is possible for bitmap, RLE, and non-compressed data blocks to coexist in the same data file.

When a compressed data block is brought into the data cache, Hyperion Essbase expands the block to its full size, regardless of the scheme that was used to compress it.
When Hyperion Essbase stores a block on disk, Hyperion Essbase treats the block the same whether the block was compressed or non-compressed when it was brought into the data cache. In either case, Hyperion Essbase compresses the block according to the specified compression type (including not compressing the block if No Compression is specified).
If compression is not enabled, Hyperion Essbase writes out the fully expanded block to disk.

Storage Allocation

Hyperion Essbase automatically allocates storage for index (ESSxxxxx.IND) and data (ESSxxxxx.PAG) files. By default, Hyperion Essbase uses the volume where the ARBORPATH directory resides and uses all the available space on that volume. If you want to use multiple volumes to store your index and data files or if you want to install Hyperion Essbase on one volume and store files on another volume, use the disk volumes setting.

You use the disk volumes setting to control how much space Hyperion Essbase uses to store index files and data files and on which volumes (drives) Hyperion Essbase stores index files and data files.

With the disk volumes setting, you can specify the name of a disk (or a letter corresponding to a disk drive, such as C). If you do not specify disk volumes setting, Hyperion Essbase automatically stores the data and index files in the database directory (for example,\ESSBASE\SAMPLE\BASIC).

Hyperion Essbase creates new data and index files when either of the following occurs:

The total sizes of all files reach the maximum size specified in the disk volumes setting. By default, the total is the sum of all index and data file sizes. If you specify Index under File Type, the total refers to the sum of all index files on a particular volume. Likewise, if you specify Data under File Type, the total refers to the sum of all data files on a particular volume.
For example, suppose you want to use up to 12 GB for Hyperion Essbase files on volume E, 16 GB on volume F, and 16 GB on volume G. Hyperion Essbase creates a new file on volume F when the sizes of the index and data files reach 12 GB on volume E and more data needs to be written out to disk.
The size of an individual index or data file on any volume exceeds two gigabytes. In the above example, suppose volumes E and F have reached their capacities and Hyperion Essbase is using volume G. Figure 42-3 illustrates this example.
In volume G, Hyperion Essbase creates file ESS00001.IND and fills it to the default limit of 2 GB.

In volume G, Hyperion Essbase creates file ESS00001.PAG and fills it to 1 GB.

You have specified a limit of 16 GB on volume G, and you have used 3 GB. You have 13 GB left to use on volume G, but ESS00001.IND has reached the maximum file size of 2 GB. The next time Hyperion Essbase needs storage when writing index files to disk, Hyperion Essbase creates a new file on volume G and names it ESS00002.IND. Hyperion Essbase then fills ESS00002.IND to its 2 GB limit and creates ESS00003.IND. Hyperion Essbase follows the same procedures for data files.

Figure 42-3: Example of How Hyperion Essbase Stores Files Across Volumes

Hyperion Essbase names files consecutively, starting with ESS00001.xxx, where xxx is IND for an index file and PAG for a data file, and continuing up to ESS65535.xxx. This naming convention applies to each volume, so in the above example, volumes E, F, and G each have files named ESS00001.PAG and ESS00001.IND.

You can specify the disk volumes setting from Hyperion Essbase Application Manager menu (select Database > Settings and click the Storage tab).

You can also use alter database in MaxL or the SETDBSTATEITEM and SETDBSTATE commands in ESSCMD to specify the disk volumes setting. For more information, see the online Technical Reference in the DOCS directory.

For more information on how to specify disk volumes and related settings, see Specifying Disk Volumes.

Fragmentation

Even when data compression is enabled, a small amount of fragmentation can occur. Fragmentation is unused disk space. Fragmentation is created when Hyperion Essbase writes a data block to a new location on disk and leaves unused space in the former location of the data block.

The Hyperion Essbase kernel merges adjacent fragments into increasingly larger fragments so that unused space is more likely to be re-used.

Index and Data File Sizes

You can view index file (.IND file) and data file (.PAG file) names, counts, sizes, and totals and you can determine whether each file is presently open in Hyperion Essbase. From Hyperion Essbase Application Manager, select Database > Information and click the Files tab to view this information.

You can use the LISTFILES command in ESSCMD to view index file (.IND file) and data file (.PAG file) names, counts, sizes, and totals and to determine whether each file is presently open in Hyperion Essbase. See the online Technical Reference in the DOCS directory for information about the command.

Note:

The file size information that is provided by the Windows NT operating system for index and data files that reside on NTFS volumes may not be accurate. The file size information provided by Hyperion Essbase Application Manager and by LISTFILES is accurate.

Database Restructuring

Usually, as your business changes, your Hyperion Essbase database outline changes. Some database outlines change frequently. Hyperion Essbase has two common ways to change a database outline:

Using the Outline Editor
Using dimension building

If changes to your outline are relatively minor, such as renaming a member name, there is little impact to your Hyperion Essbase server. More significant changes, such as moving a member to a different parent, require recalculation of data. The most significant changes are those that affect the way data is stored on the disk. When the data storage arrangement needs to change, you must restructure the database. Changes that require restructuring the database are very time-consuming, unless you discard your data before restructuring.

Hyperion Essbase uses three types of restructure operations:

Full restructure: If a member of a dense dimension is moved, deleted, or added, Hyperion Essbase restructures the blocks in the data files and creates new data files. When Hyperion Essbase restructures the data blocks, it regenerates the index automatically so that the index entries point to the new data blocks. Hyperion Essbase marks all restructured blocks as dirty, so you need to recalculate the database after a full restructure. Full restructuring is the most time-consuming of the restructures and, for large databases, can take a relatively long time to complete.
Sparse restructure: If a member of a sparse dimension or a member of an attribute dimension is moved, deleted, or added, Hyperion Essbase restructures the index and creates new index files. Restructuring the index is relatively fast; the amount of time required depends on the size of the index.
Outline-only restructure: Hyperion 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.

If you are using Intelligent Calculation in your database, then any time data blocks are restructured, all restructured blocks are marked as dirty, and the next default Intelligent Calculation is a full calculation. If you change a name or a formula, Hyperion Essbase does not mark the block as dirty. Therefore, you must use a method other than full calculation to recalculate the member or the database.

If you change your outline frequently, you may want to consider enabling incremental restructuring. See Incremental Restructuring.


For more information about...	See...
Intelligent Calculation	Using Intelligent Calculation to Optimize Calculation
Sparse and dense dimensions	Basic Architectural Elements
Attribute dimensions	Working with Attributes
Dimension building	Introducing Dynamic Dimension Building
The Outline Editor	Creating and Changing Database Outlines

The Hyperion Essbase Process for Restructuring Data

When Hyperion Essbase restructures both the data blocks and the index, it uses the following files:

dbname.IND
ESSxxxxx.IND
ESSxxxxx.PAG
dbname.OTL
dbname.ESM
dbname.TCT

To perform a full restructure, Hyperion Essbase does the following:

Creates temporary files that are copies of the.IND, .PAG, .OTL, .ESM, and.TCT files. The temporary files substitute another character for the last character of the file extension, so the temporary file names are dbname.INN, ESSxxxxx.INN, ESSxxxxx.PAN, dbname.OTN, dbname.ESN, and dbname.TCU.
Reads the blocks from the old database files, restructures them in memory, and then stores them in the new temporary files. This step takes the most time.
Removes the old database files, including.IND, .PAG, .OTL, .ESM, and .TCT files.
Renames the temporary files to the correct file names: .IND, .PAG, .OTL, .ESM, and.TCT.

If an error or system failure occurs while Hyperion Essbase is restructuring, it is most likely to occur during step 2. To recover, you can simply restart the database. However, you need to delete the temporary files, both to free up disk space and to avoid conflicts the next time you restructure the database.

If a system failure occurs during steps 1, 3, or 4, then you need to review the directory of your disk and evaluate how far the restructuring has progressed. Recovering involves removing the temporary files, or, if all but step 4 is complete, renaming the temporary files to the correct file names.

When Hyperion Essbase does a sparse restructure (restructures just the index), it uses the following files:

ESSxxxxx.IND
dbname.OTL
dbname.ESM

To perform a sparse restructure, Hyperion Essbase does the following:

Renames the old dbame.ESM file to dbname.ESR.
Renames the old ESSxxxxx.IND files to ESSxxxxx.INM.
Creates new index files (ESSxxxxx.IND) to store index information that is changed by the restructuring operation.
Removes the old dbname.ESR file and the old index files (ESSxxxxx.INM).

If a system failure occurs during any of these steps, you can recover by restarting the database.

Optimization of Restructure Operations

If your outline changes frequently, analyze your outline and the types of changes you are making. Remember that changes to sparse dimensions or attribute dimensions are relatively fast because only the index needs to change. Changes to dense dimensions are relatively slow because the data blocks need to be rebuilt.

The following are the types of restructure operations, in order of decreasing performance:

Outline only (no index or data files)
Sparse (only index files)
Full (index files and data files) due to added, deleted, or moved members and other operations as listed in Table 42-2
Full (index and data files) due to a dense dimension becoming sparse or a sparse dimension becoming dense

The following operations are slow:

Changing a dense dimension to a sparse dimension
Changing a sparse dimension to a dense dimension

Actions That Improve Performance

To improve performance during restructure, consider doing the following:

Restructure only input-level or level 0 data. Restructuring only input-level and level 0 data requires less disk space than restructuring all data. When you change the outline such that Hyperion Essbase needs to restructure data, Hyperion Essbase displays a dialog box that you can use to choose to restructure only input-level or level 0 data. See Saving a Modified Outline.
If you change some dimensions frequently, make them sparse.

Incremental Restructuring

If you make frequent changes to your outline, you may want to consider enabling incremental restructuring. When incremental restructuring is enabled, Hyperion Essbase defers restructuring so that a change to the database outline or to a dimension does not cause structural change. Hyperion Essbase restructures the index and, if necessary, the affected block the next time the block is accessed.

When incremental restructuring is enabled, Hyperion Essbase defers restructuring for many database changes. See Table 42-2.

The following changes override incremental restructuring; that is, they result in immediate restructuring, regardless of whether incremental restructuring is enabled:

Adding or deleting a non-attribute dimension
Deleting a stored member of a sparse dimension
Changing a dimension definition from sparse to dense or from dense to sparse

Certain member additions and certain changes to sparse dimensions can also trigger immediate restructuring. For more information, see Table 42-2.

You can enable incremental restructuring for any of the following:

An individual database in an application
All databases in an application
All databases in all applications

To enable incremental restructuring, use the INCRESTRUC parameter in the ESSBASE.CFG file. For more information on the INCRESTRUC parameter and syntax, see the online Technical Reference in the DOCS directory.

Hyperion Essbase logs outline changes in an internal file, database_name.OCL. Hyperion Essbase clears the file when it does a full database restructure or when you clear or reset the database. The file database_name.OCL can grow quite large in the meantime. To clear this file, issue VALIDATE in ESSCMD. VALIDATE causes Hyperion Essbase to restructure any blocks whose restructure was deferred; thus, the file is cleared. When you issue VALIDATE, make sure that the database is not in read-only mode (read-only mode is used for archiving). For more information on the VALIDATE command, see Checking Structural Integrity.

Note:

If you are using linked reporting objects (LROs) in a database, incremental restructuring is automatically disabled on that database. When you enable incremental restructuring for all databases, the presence of an LRO in a database disables INCRESTRUC for that database, but does not affect the other databases on the server.

Restructuring Considerations

This section discusses features and options that cause Hyperion Essbase to track additional information and that, therefore, affect performance.

Outline Change Log

If you activate the outline change log, Hyperion Essbase records all activity that affects the outline (member name changes, member moves, and so on). The more changes you make to the outline, the more updates Hyperion Essbase must make to the log. By default, Hyperion Essbase does not log outline changes. To activate the log, set OUTLINECHANGELOG to True in the ESSBASE.CFG file. For more information about the log, see Outline Change Log File.

IBM Relational Storage Manager

If you use the relational storage manager of the IBM DB2 OLAP Server, any changes to metadata are reflected in both Hyperion Essbase and the DB2 OLAP Server. Metadata is data contained in the database outline that describes the values within a database. Dimension and member names are metadata. Data that describes values is stored only on the DB2 OLAP Server.

Hyperion Essbase Partitioning Option

When you use Hyperion Essbase Partitioning, Hyperion Essbase tracks outline changes so that you can synchronize the database outlines across partitions. Tracking outline changes slows restructuring performance, particularly when there are many structural changes.

If Hyperion Essbase restructures data when you are using partitioning, perform the following steps to make sure that data is synchronized across partitions:

Validate the partitions. Use the Validate page of the Partition Wizard. See Validating the Partition for more information.

Note: To validate a partition, you must have DB Designer or higher privileges.
Synchronize the outlines of the partitions. Select Database > Synchronize Outline to open the Synchronize Outline dialog box. See Synchronizing Outlines for more information.

You can use ESSCMD to synchronize outlines. See the online Technical Reference in the DOCS directory for information about these commands. See Performing Interactive and Batch Operations Using ESSCMD for information about ESSCMD.

Impact of Common Outline Changes

The following table shows all operations that affect data values and restructuring. It is a good idea to recalculate the database after any type of restructure operation.

The third column in the table refers to incremental restructuring. See Incremental Restructuring if the term is unfamiliar to you.

For information about dynamic calculation members, see Dynamically Calculating Data Values. For information about attribute dimensions, see About Attributes.

Note:

If you are using Hyperion Essbase Partitioning Option, restructuring affects only the local, target database, not the database to which you are connected.

*Table 42-2: How Actions Affect Databases and Restructuring*
Action	Data and Restructure Implications	Incremental Restructuring Implications (If Enabled)
Rename member	None	None
Change member formula	Data needs to be recalculated to reflect changes in formulas. No restructure.	None
Delete member of sparse dimension	Data needs to be recalculated to reflect changes to relationships. Hyperion Essbase deletes from the index file pointers that point to blocks represented by the deleted member. Because the blocks are no longer pointed to, they become free space.	Hyperion Essbase restructures the index (overrides incremental restructure). For shared and label-only members: restructure deferred.
Delete member of attribute dimension	None	None
Delete member of dense dimension	Data needs to be recalculated to reflect changes to relationships. Hyperion Essbase restructures the data files to reflect a changed block size. Hyperion Essbase restructures the index.	Restructure deferred.
Delete member with shared property in sparse or dense dimension	Data needs to be recalculated. The data remains associated with the original member name, but because the parent of the shared member may have depended on the child data, recalculation is needed. No restructure.	None
Add member to sparse dimension	Data for the new member needs to be loaded or calculated to derive new values. Hyperion Essbase restructures the index.	Restructure deferred.
Add member to dense dimension	Data for the new member needs to be loaded or calculated to derive new values. Data needs to be recalculated. Hyperion Essbase restructures the data files to reflect a changed block size. Hyperion Essbase restructures the index.	Restructure deferred.
Add member to attribute dimension	None	None
Add member with shared property to sparse or dense dimension	Data needs to be recalculated. The new shared member affects the consolidation to its parent. No restructure.	None
Redefine Dynamic Calc member as Dynamic Calc And Store	For dense dimension members: Hyperion Essbase restructures both index and data files. For sparse dimension members: No restructure.	Restructure deferred.
Redefine Dynamic Calc And Store member as Dynamic Calc	None	None
Redefine regular dense dimension member as Dynamic Calc And Store	None	None
Redefine regular dense dimension member as Dynamic Calc	Hyperion Essbase restructures both index and data files.	Restructure deferred.
Redefine sparse dimension Dynamic Calc And Store or Dynamic Calc member as regular member	No restructure.	No restructure.
Redefine sparse dimension regular member as Dynamic Calc or Dynamic Calc And Store	Hyperion Essbase restructures both index and data files.	Restructure deferred.
Redefine dense dimension Dynamic Calc And Store member as regular member	No restructure.	No restructure.
Redefine dense dimension Dynamic Calc member as regular member	Hyperion Essbase restructures both index and data files.	Restructure deferred.
Redefine dense dimension regular member as Dynamic Calc member	Hyperion Essbase restructures both index and data files.	Restructure deferred.
Add, delete, or move sparse dimension Dynamic Calc member	Hyperion Essbase restructures only index files.	For member add or delete: restructure deferred. For member move: Hyperion Essbase restructures only index files (overrides incremental restructure).
Add, delete, or move sparse dimension Dynamic Calc And Store member	Hyperion Essbase restructures only index files.	For member add: restructure deferred. For member move or delete: Hyperion Essbase restructures only index files (overrides incremental restructure).
Add, delete, or move a dense dimension Dynamic Calc And Store member	Hyperion Essbase restructures both index and data files.	Restructure deferred.
Add, delete, or move a dense dimension Dynamic Calc member	No restructure.	No restructure.
Move regular member within a sparse dimension	Data needs to be recalculated to reflect changes in consolidation. Hyperion Essbase restructures the index file.	Hyperion Essbase restructures the index file (overrides incremental restructure).
Move regular member within a dense dimension	Data needs to be recalculated to reflect changes in consolidation. Hyperion Essbase restructures both index and data files.	Restructure deferred.
Move an attribute dimension member	None	None
Change dense/sparse setting	Data needs to be recalculated. Hyperion Essbase restructures both index and data files.	Hyperion Essbase restructures both index and data files (overrides incremental restructure).
Change label only setting	Data needs to be recalculated. Hyperion Essbase restructures both index and data files.	Restructure deferred.
Change shared member setting	Data needs to be recalculated to reflect the changed data value of the child. Hyperion Essbase restructures both index and data files.	Restructure deferred.
Change properties (other than dense/sparse, label, or shared)	Data may need to be recalculated to reflect changed consolidation properties, such as changing time balance from first to last.	None
Change the order of two sparse dimensions	No calculation or data load impact. Hyperion Essbase restructures the index.	Hyperion Essbase restructures the index (overrides incremental restructure).
Change the order of two dense dimensions or change the order of a dense and sparse dimension	Data needs to be recalculated. Hyperion Essbase restructures both index and data files.	Hyperion Essbase restructures both index and data files (overrides incremental restructure).
Change the order of dimensions	Data needs to be recalculated. Hyperion Essbase restructures both index and data files.	Hyperion Essbase restructures both index and data files (overrides incremental restructure).
Change the order of attribute dimensions	None	None
Create, delete, clear, rename, or copy an alias table	None	None
Import an alias table or set member alias	None	None
Change the case-sensitive setting	None	None
Name a level and generation	None	None
Create, change, or delete a user-defined attribute	None	None
Change a member alias or add an alias to a member	None	None

The Hyperion Essbase Process for Restructuring After Outline Changes

This section tells you what to expect when you change, add, or delete dimensions.

Saving a Modified Outline

In the Outline Editor, if you change a dimension in the outline, such that Hyperion Essbase needs to restructure the data file, Hyperion Essbase displays the following dialog box when you save the outline changes:

Figure 42-4: Restructure Database Dialog Box

In the Restructure Database dialog box, you specify a restructuring option for blocks. If the database contains data, you need enough free disk space on the server to create a backup copy of the database. Backup ensures that any abnormal termination during the restructure process does not corrupt the database.

All data--This option preserves all data, but is generally slower than the other options.
Level 0 data--This option preserves data only for level zero (leaf node) members. If you change the database and need to recalculate and if all data required for the calculation is in level zero members, this is the optimal restructure option.
When you select level 0 data, all upper level blocks are deleted before restructuring. This option reduces the disk space required to restructure and improves calculation time when the database is recalculated. Hyperion Essbase recreates the upper-level blocks when you calculate the database.
Input data--This option preserves only the blocks that contain data that is loaded. Many applications contain data that is entered at parent levels. This option prevents any blocks created by data loading from being deleted, whether they are upper-level or lower-level blocks. If you change the database and need to recalculate and if you load data into various levels of the outline, this is the optimal restructure option.
The Input data option deletes all blocks that contain strictly calculated values before restructuring. This option reduces the disk space required to restructure and improves calculation time when the database is recalculated.
Discard all data--This option preserves no data. Use this option when you expect to reload the data or when the outline is so radically changed that no existing data applies.

Saving an Outline with One or More New Standard Dimensions

If you add one or more new standard (non-attribute) dimensions, then any data previously existing in the database must be associated with a member of each new dimension. For example, adding a dimension called Channel to the Sample Basic outline implies that all previous data in Sample Basic is associated with a particular channel or the sum of all channels. See Adding and Deleting Standard Dimensions and Stored Members for more information.

If you add one or more new standard dimensions, the following dialog box is displayed:

Figure 42-5: Added Dimensions Dialog Box

Saving an Outline with One or More Deleted Standard Dimensions

If you delete one or more standard (non-attribute) dimensions, then the data associated with only one member of each deleted dimension can be retained. For example, removing a dimension called Market from the outline implies that the data that remains in the database after the restructure operation is associated with a specified member of the Market dimension. See Adding and Deleting Standard Dimensions and Stored Members for more information.

One application of this technique is to delete a dimension from the database, such as Market, save the database as another name, such as New York, and specify the member to keep, such as New York. The new database is a working database for the New York market, and analysts in New York can use it for their analysis.

If you delete one or more dimensions, the following dialog box is displayed:

Figure 42-6: Deleted Dimensions Dialog Box

Note:

Hyperion Essbase may display a "Restructuring not required" message, yet still perform an index-only restructure. This event is most likely to occur if you make changes to a sparse dimension.

If you try to cancel a restructure operation, Hyperion Essbase may issue a "Can't cancel" message. If such a message is displayed, Hyperion Essbase is performing final cleanup and it is too late to cancel.

If you delete an attribute dimension, Hyperion Essbase deletes the associations to its base dimension. See Working with Attributes.