Essbase® Analytic Services Database Administrator's Guide | | Update Contents | Previous | Next | Print | ? | |
Information Map | |
This chapter describes how to back up a database and lists the Analytic Services files that are essential to restoring a database from backups.
This chapter includes the following sections:
If you are migrating from a previous release of Analytic Services, see the Essbase Analytic Services Installation Guide.
A key part of a database maintenance routine includes regular backups of Analytic Services data. It is important to integrate regular database backups into 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:
This section tells you which files should be backed up regularly and describes each backup method.
You should regularly back up the server, application, and database files listed in Table 65:
File |
Location |
---|---|
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.
For a full list and description of all Analytic Services files, see Understanding How Analytic Services Files Are Stored.
A common method of creating database backups is by doing a file system backup of the Analytic 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 Analytic Services directory structure. Be sure to back up data on every disk volume Analytic Services uses. For information about data storage on multiple volumes, see Specifying Disk Volumes.
In most cases, backups occur after Analytic Services applications and databases, as well as the Agent, are shut down. If any Analytic Services databases must be up and running at the time of backup, follow these steps:
You can 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:
Tool |
Instructions |
For more information |
---|---|---|
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.
The begin-archive utility performs the following tasks:
archive.lst
. This file is stored in the ARBORPATH\app\appname\dbname
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.
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 data without using a begin-archive utility, make sure that all Analytic Services applications are closed and that all users are logged off during the backup process. Otherwise, you risk corrupting the database.
After putting the database in read-only mode, you are ready to perform the backup.
To back up data, use a third-party backup utility to back up the files listed in
archive.lst
and
the files listed in Files to Back Up. Alternatively, you can back up the entire Analytic Services directory structure.
For information on restoring files from backup, see Restoration of Data from Backups.
After performing the backup, return the database to read-write mode.
To return the database to read-write mode, use either of the following methods:
Tool |
Topic |
Location |
---|---|---|
The end-archive utility performs the following tasks:
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.
You can back up data by exporting it. Exporting data copies it to a 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:
Note: You can export subsets of data by creating reports. For a discussion and examples of the process, see Exporting Data Using Report Scripts.
Using export to back up data provides the following advantages:
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.
Using export to back up data provides the following disadvantages:
To export data, use either of the following methods:
Tool |
Instructions |
For More Information |
---|---|---|
Note: To improve export performance, you can export data in parallel to a specified number of files.
All methods require the same basic information:
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.
Some file management systems do not support text files larger than 2 GB. On any operating system, if Analytic Services anticipates that an export file exceeds 2 GB, it creates two or more export files, as needed.
When Analytic Services 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, Analytic Services creates three files, naming them expJan.txt
, expJan_1.txt
, and expJan_2.txt
. Exported data files can be reloaded in any sequence.
To reload exported data, use any of the following methods:
Tool |
Topic |
Location |
---|---|---|
When you reload data that has been exported, Analytic Services 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, Analytic Services recalculates every data block.
If you export all data in a database and then reload, Analytic Services marks all blocks in the database as input blocks. Consequently, if you try to clear data, no data is cleared because the database contains no non-input blocks.
When you reload data that has been exported, Analytic Services 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;
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.
Essbase now compares the security backup file essbase.bak to the security file essbase.sec
at specified intervals instead of only when Analytic Server starts.
To change the frequency of these backup file comparisons, use either of the following methods:
Tool |
Instructions |
For more information |
---|---|---|
Enter the time interval in the Check for inactivity every option of the Security tab when you edit Analytic Server properties. |
||
Note: You can manually update the security backup file at any time using Administration Services. See "Updating the Security Backup File" in Essbase Administration Services Online Help.
Review these facts before changing the interval value:
Essbase always updates the backup file if it does not match the security file when the two files are compared, regardless of which tool is used to trigger the comparison. The backup file is updated only if a difference exists between the security file essbase.sec and the security backup file essbase.bak
.
Caution: If Essbase stops running unexpectedly for any reason, such as a freeze or crash, or as the result of terminating a process, do not restart Analytic Server until you copy the backup file essbase.bak
to the security file essbase.sec
. If you do not perform the copy first, when Analytic Server starts, Essbase notes that essbase.sec is corrupt, creates an empty security file and copies it to essbase.bak
, thus destroying the backup of your security information.
These files are all key components of an Analytic Services 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 (see Database Backups.)
There have been cases in which database files have become corrupted. In such situations, the database is not able to start up on Analytic 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 the following files:
After the files are deleted, restart the database and reload from data files or from export files created prior to the corruption.
![]() |