Essbase normally maintains correct and synchronized data and index files. Trouble usually arises when Essbase applications are abnormally terminated. When an abnormal termination occurs at the wrong” point during processing, data or index files may not be written properly to disk, resulting in database corruption. This can happen for various reasons:
– a power failure or the server Machine is turned off abruptly
– the server operating system fails or is shut down
– an operator kills an Essbase task on the server
– some outside influence causes a fatal interruption of application processing
– a user attempts to access data within a previously corrupted database
– a bug in Essbase causes the application to crash
Essbase databases contain data files (PAG) and index files (IND). The data files store blocks of data values or cells. Index files identify where in the data files each block of data resides so that during data retrieval, load, or calculation, Essbase can extract the values for processing. Because these files are stored separately, they must remain completely synchronized, or else the index would not reference the correct data blocks.
Under normal circumstances, Essbase ensures these files are correct. Essbase employs a number of techniques internally to minimize the potential for corruption, including a “safe-write” methodology which uses space in the files to store both current and previous copies of changed data. In the event of an abnormal termination, Essbase can usually recover to a prior, known good point in time. Unfortunately, sometimes events occur which leave the files in an unsynchronized state.
If the data and index files are not synchronized, the database is corrupt. The index is the only means for interpreting the data files, so if the index is bad, the data is lost. There is no other utility which can read the data files and recover the data. This underscores the importance of having a good backup strategy.
Depending on the extent of the corruption, some portions of the database may still be accessible. This can be beneficial in recovery efforts, but it also means that users may be working with a corrupted database and not know it. Some time may pass before someone accesses the “bad” spot in the database and discovers the corruption. When this happens, the Essbase application process on the server will usually “crash” and produce an exception log (XCP file). The user will get a message indicating a network error because the server is no longer responding to the client.
In some cases, no one notices these Crash Events. The users simply reconnect, the database is reloaded, and they may continue in this fashion for a long time. The problem is compounded, and sometimes degrades the database to the point where it can no longer even start up. At this point, the only recourse is to recover the files from file system backup.
Here is a sampling of error messages which may indicate a corrupted Essbase database (other, similarly worded messages may also occur):
1006010 Invalid block header: Block’s numbers do not match
1006016 Invalid block header: Illegal block type
1070020 Out of disk space. Cannot create a new index file.
1070026 Corrupted Node Page in the B+tree. [%s] aborted
1005016 Unable to Read Information From Page File
1006002 Unable to Store Information In Page File
1006004 Unable to Read Information From Page File
1080009 Fatal Error Encountered. Please Restart the Server…
1070018 Invalid file handle [%s]. [%s] aborted.
Refer the below URL from Oracle for fix and possible root cause.