This post provides information on improving system performance by using best practices in reporting.
Running reports is a very resource-intensive operation and has the potential to be one of the biggest factors in poor system performance.
To help keep reports from affecting your system performance, you should isolate the reporting function as much as possible.
• Isolate reporting in time.
• Isolate reporting by user.
• Isolate reporting by cluster and application server.
• Isolate reporting by database.
• Manage the report database.
• Configure the report server.
Run Resource-Intensive Reports in Off-Peak Hours
Many reports that consume significant resources are not needed immediately, and do not necessarily need to be run on up-to-the-minute data. You should run such reports in off-peak hours, such as overnight or on the weekend. Time-based reports such as end-of-month and end-of-quarter reports can be run in off-peak hours, on a copied database from a specific date and time. Because you do not need to run these reports on the current database, you can protect the production database from being slowed by these reports.
Limit the Use of Reports
The more users that run
reports, and the more reports they run (especially database-intensive reports), the greater the potential effect on system performance. You should establish business practices to help manage the amount
of report use, especially during peak system-use hours. Limit the number of users who can run reports. Limit the number of reports that users can run.
During peak business hours, try to limit report use to reports that users need for their daily work, such as Print
Work Orders, Print POs, and so on.
Reporting
Run Reports on a Separate Cluster
If your users do extensive reporting, a good practice is to establish one or more application servers that are dedicated to running reports. You can size the clustering of report application servers based on demand. Establish a separate cluster for running scheduled reports (cron jobs).
Provide a Separate Database for Reporting
Some customers report that providing a separate database to run reports on is the single practice that gives the greatest boost to system performance.
Configure a separate
Maximo database that has a copy of the production data, and use that as an off-line database for reporting. Mirror the Maximo production database on a separate database server, and run resource-intensive reports on the mirror database. Create a separate Maximo application that connects to the reporting database and synchronize the production and reporting databases periodically.
For example, you might synchronize the databases at the end of every day or once a week, depending on your needs.
With this setup, reports that require more system resources can be run by just a few administration users. Because they are run on a separate mirror database, these reports do not affect performance of the production system.
Manage Your Reports
By default, executed reports are saved to the Actuate Encyclopedia. Over time, the volume of saved reports can affect report performance. It is a good practice to periodically delete unneeded executed reports from the Encyclopedia. You can delete unneeded reports from the Encyclopedia by enabling the Actuate AutoArchive feature in the Management Console. AutoArchive sweeps the Encyclopedia for documents that are older than a specified age and deletes them.
Configure the Actuate Report Server if necessary
By default, the Actuate report server is configured for typical usage. The basic single-server setup is typically enough to support 100 users. Actuate is a resource-intensive application. Allocate a minimum of two processors and 2 GB of memory to run Actuate. If you are running a large number of reports, consider a load-
