Backing Up and Restoring a Hyperion Essbase Database

Backing Up a Database
A key part of a database maintenance routine includes regular backups of Essbase data. It is important to integrate regular database backups into your production server maintenance. The frequency of backups is dependent upon the volatility of the database and server environment, as well as upon the demand for quick database restores in the event of server crashes. There are two methods of backing up a database: Preparing the database for file system backup Exporting, which makes a copy of data in an ASCII text format This section tells you which files should be backed up regularly and describes each backup method.

Files to Back Up
You should regularly back up the server, application, and database files listed in following table.

It is important to back up all .ind and .pag files related to a database because a single database can have multiple .ind and .pag files. Remember, the Agent should be shut down before the essbase.sec file is backed up.

File System Backup

A common method of creating database backups is by doing a file system backup of the OLAP Server. You can perform the backup using the file system backup software of your choice. You can back up specific directories or files, or you can back up the entire Essbase directory structure. In most cases, backups occur after Essbase applications and databases, as well as the Agent, are shut down. However, due to user requirements, some Essbase databases must be up and running at the time of backup.

Placing a Database in Read-Only Mode

Essbase provides a way to prepare a database for backup when the database must remain running during the backup process. Placing the database in read-only (or "archive") mode protects the database from updates during the backup process. After you perform the backup using the third-party backup utility of your choice, you then return the database to read-write mode. To place a database in read-only mode, use either of the following methods:

Note: If you try to cancel the BEGINARCHIVE ESSCMD command or the 'alter database begin archive' MaxL statement and you receive a "can't cancel" message, the system is most likely in the final stage of writing items to the drive and has reached the point where the operation cannot be cancelled. To return the database to read-write mode, use either of the following methods:

The begin-archive utility does the following: Commits any modified data to disk. Switches the database to read-only mode. Reopens the database files in shared, read-only mode. Creates a file containing a list of files that need to be backed up. By default, the file is called archive.lst. It is stored in the database directory.

If a user tries to modify data during the backup process, an error message informs the user that data is in read-only mode for backup. The end-archive utility does the following: Returns the database to read-write mode. Re-opens database files in exclusive, read-write mode. Begin-archive and end-archive utilities do not perform the backup; they simply protect the database during the backup process. Caution: If you back up your data without using a begin-archive utility make sure that all Essbase applications are closed and that all users are logged out during the backup process. Otherwise, you risk corrupting the database.

Performing a Backup
After putting the database in read-only mode, you are ready to perform the backup. To backup data, use a third-party backup utility to back up the files listed in archive.lst. Make sure you back up the files listed in Files to Back Up. Alternatively, you can back up the entire Essbase directory structure.

Returning a Database to Read-Write Mode

After performing the backup, you need to return the database to read-write mode. To return the database to read-write mode, issue an 'alter database end archive' statement in MaxL, or the ENDARCHIVE command in ESSCMD. Note: You must use the end-archive utility to put the database back into read-write mode, even if you shut down and restart the database. The end-archive utility does not restart the database.

Using Export to Back Up Data

You can back up data by exporting it. Exporting data copies it to an ASCII text file that you specify; it does not compress data. The export file contains data only and does not include control, outline, or security information. You might consider exporting data for the following reasons: To transfer data across platforms To back up only a certain portion of the data; for example, level 0 blocks

 To create an exported file in text format, rather than binary format Note: You can export subsets of data by creating reports.

Export Considerations
Using export to back up data provides the following advantages: You can use the resulting ASCII files to load data from the source database into databases on other platforms. When loading an export file into a database, it is important that the database outline contains all the members found within the export file. If not, the load will fail. Also, if the outline changes between the time that the export file is created and reloaded (and the new outline contains all the members found within the export file), the load time might be significantly higher than if the outlines were identical. During an export, data integrity is verified because every block is checked to confirm whether corresponding page and index files match. You can reduce fragmentation in a database by exporting data into an ASCII file, clearing all data from the database, and reloading the ASCII file. You can export a database in column format from Application Manager or MaxL. Then, you can use a data load rules file to load the columnformatted file. Using column format is helpful when you need to manipulate the export file. Using export to back up data provides the following disadvantages: Because dynamic calculations are not executed at the time of the export, only stored data and data from previously calculated Dynamic Calc and Store members are included in the export. At the time of a database export, Essbase users cannot write to the database. Users receive an error message if they try to write to the database during an export. After an export has started, users can do read operations. Exports of large databases require considerable amounts of time, time during which users can only read the data.

Exporting Data
To export data, use any of these clients:

All methods require the same basic information: The amount of data to export: All data Level 0 blocks only (blocks containing only level 0 sparse member combinations) Data from input blocks only (blocks containing data from a previous data load or spreadsheet Lock & Send) Whether to export data in a columnar or non-columnar format To facilitate loading the exported data into a relational database, export the data in columns. In each row, the columnar format displays a member name from every dimension. Names can be repeated from row to row. The columnar format provides a structure to the exported data, so that it can be used for further data processing by applications other than Essbase tools. In non-columnar format, sparse members identifying a data block are included only once for the block. Because the export file in non-columnar format is

smaller than in columnar format, reloading a file in non-columnar format is faster. The export data file names

Improving Export Performance

To improve export performance, you can now export data in parallel to a specified number of files, using the export statement in MaxL or the PAREXPORT command in ESSCMD.

Exporting Files Larger Than 2 GB

Some file management systems do not support ASCII files larger than 2 GB. On any operating system, if Essbase anticipates that an export file exceeds 2 GB, it creates two or more export files, as needed. When Essbase creates multiple export files, it uses the requested file name for the main file. An underscore and a sequential cardinal number are appended to the names of the additional files, starting with _1. For example, if the requested file name is expJan.txt and the exported data would exceed 4 GB, Essbase creates three files, naming them: expJan.txt, expJan_1.txt, and expJan_2.txt. Exported data files can be reloaded in any sequence.

Reloading Exported Data

To reload exported data, use any one of the following tools:

When you reload data that has been exported, Essbase marks the data as input data. If you reload data exported from level 0 blocks or input blocks, you must recalculate the database after reloading. When you recalculate the database, Essbase recalculates every data block. If you export all data in a database and then reload, Essbase marks all blocks in the database as input blocks. Consequently, if you try to clear data by selecting Database > Clear Data > Non-Input Blocks from Application Manager, no data is cleared because the database contains no non-input blocks. When you reload data that has been exported, Essbase also marks the data blocks as dirty. If you had calculated the database prior to exporting it, to save time during the next calculation, you should set the status of the blocks as clean. If you had not calculated the database prior to exporting it, you do not need to set the status of the blocks as clean. To clean the status of the blocks in a database after exporting all data and reloading, you can run the following calculation script: Set ClearUpdateStatus Only; Calc All;

Restoring Data from Backups

To restore a database, replace the files on disk with the corresponding files from backup. See Files to Back Up for a list of files that should be backed up on a regular basis. The application should be stopped, unless you are restoring from an export file. In that case, ensure the application is not accepting client connections.

Essential Database Files

These files are all key components of an Essbase database:

If there is a problem with any one of these files, the entire database becomes corrupted. The database must then be restored from backups or reloaded from exports. There have been cases in which database files have become corrupted. In such situations, the database is not able to start up on the OLAP Server. Therefore, no data can be reloaded to restore the database. In these cases, the only way to restore the
database is to delete all of the following files:

essn.pag essn.ind dbname.esm dbname.tct dbname.ind

After the files are deleted, restart the database and reload from data files or from export files created prior to the corruption.

Backing Up Aggregate Storage Applications The file structure used by aggregate storage applications to store application and database information differs from the file structure used by block storage applications use. The following table lists the major directories and files associated with aggregate storage applications.

To back up an aggregate storage database, ensure that the application is stopped and use the operating system to copy the entire application directory: arborpath\app\appname\. Note: The ESSCMD command BEGINARCHIVE and the MaxL statement alter database begin archive do not support aggregate storage databases.