Handling Errors and Troubleshooting Analytic Services Skip Navigation
Essbase® Analytic Services Database Administrator's Guide | Update Contents | Previous | Next | Print | ? |
Information Map

Handling Errors and Troubleshooting Analytic Services


This appendix describes tools that you can use to diagnose errors, and suggests methods for correcting some errors:

Note: Chapters related to partitions, currency conversion, and data load have basic troubleshooting information in the relevant chapters. For information about restoring from backups, see Backing Up and Restoring Data. For information about specific error messages, see the "Error Messages Guide" in /docs/errmsgs in the Essbase installation. For information about error and exception logs, see Monitoring Data, Applications, and Databases.

Understanding Fatal Error Handling

The Analytic Server Kernel considers the following errors fatal:

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

1080022 Reinitializing the Essbase Kernel for database database_name due to a fatal error... 
 

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

1080028 Performing transaction recovery for database database_name during fatal error processing. 
 

When you see such messages, you know that the kernel shut itself down and is attempting to start up again. Check the Analytic Server log and determine whether Analytic Services issued a fatal error message just before it generated the reinitialization messages. For a review of methods used to view the Analytic Server log, see Using Analytic Server and Application Logs.

If the kernel did encounter a fatal error, in most cases you need to restart 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 Analytic Server log to see how far Analytic Services processed the operation. When in doubt, restart the operation. For descriptions of types of server interruptions and of recovery procedures, see What to Expect If a Server Interruption Occurs.

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

See Contents of the Analytic Server Log for detailed descriptions of the contents of the Analytic Server log. See Analytic Server and Application Log Message Categories for specific information about identifying the component where the error occurred.

Recovering from Full Restructure Failure

If an error or system failure occurs while Analytic Services is restructuring, it is most likely to occur during step 2 in the procedure Full Restructures.

To recover from a failure during step 2 of Full Restructures:

  1. Delete the temporary files, both to free up disk space and to avoid conflicts the next time you restructure the database.

  2. Restart the database.

To recover from a failure during step 1, step 3, or step 4 of Full Restructures:

  1. Review the disk directory and determine how far the restructuring has progressed.

  2. If all but step 4 is complete, rename the temporary files to the correct file names.

Recovering from Sparse Restructure Failure

If a system failure occurs during any step of a sparse restructure, you can recover by restarting the database.

Synchronizing Member Names in Report Scripts and Database Outlines

When you run a report, it is important to ensure that the member names in the report script match the member names in the database outline. An error displays every time the Report Extractor cannot find a matching member name, and you must correct the name in the report script before the report continues processing.

Handling Analytic Server Problems When Running Multiple Reports

Your server machine may freeze if you try to run more reports in parallel than you have assigned server thread resources.

If you are running multiple report scripts and your server freezes, check the value of the configuration file setting SERVERTHREADS in the essbase.cfg file on the server. There should be at least one thread for each report running. For example, if you are running 22 reports, the value for SERVERTHREADS should be at least 22.



Hyperion Solutions Corporation link