After a server interruption such as a crash, Essbase recovers a database, rolling back all transactions that were active when the interruption occurred. Recovery time depends on the index size. The larger the index, the longer it takes.
Essbase also recovers and consolidates free fragments (unused addressable units in the data blocks). However, free space recovery is the most time-consuming aspect of database recovery, so it is delayed by default. You must trigger free space recovery explicitly unless you have changed the default setting. See Free Space Recovery for the advantages and disadvantages of delaying free space recovery.
Essbase recovers data as soon as the server is started after a server interruption. Recovery phases:
Free space recovery is delayed until you trigger it, unless you have changed the default setting. |
A media failure (faulty disk, disk failure, or head crash) requires that you restore data from backups. See the Oracle Hyperion Enterprise Performance Management System Backup and Recovery Guide.
Do not move, copy, modify, or delete the following files: essxxxxx.ind, essxxxxx.pag, dbname.ind, dbname.esm, dbname.tct. Doing so can result in data corruption. |
The Essbase kernel uses fatal error handling to display appropriate messages and to shut down the server, depending on the error encountered. For an explanation of how fatal error handling works, see Understanding Fatal Error Handling.
For information about how transactions are rolled back after a crash, see Committed Versus Uncommitted Access.