Download 267.02 Kb.
*3 Due to the large amount of monitoring data generated, it is highly recommended that DB2 row compression (enabled by licensing the DB2 Storage Optimisation Feature) is enabled in this environment.
*3 Due to the large amount of monitoring data generated, DB2 row compression (enabled by licensing the DB2 Storage Optimisation Feature) must be enabled for these configurations.
By default OPM uses circular logging. If HADR is required then log retain is necessary and appropriate processes must be put into place to manage the archived log files.
The chart below illustrates the estimated disk breakdown by monitored data source using the “…. Detailed diagnostics” profiles:
It is highly recommended that DB2 row compression be enabled on the OPM Repository database. Row compression is enabled by default on the repository database only when the appropriate DB2 Storage Optimization Feature license is in place.
OPM produces a write intensive workload. Therefore it is important to evenly distribute the I/O across as many disk devices as possible -- this ensures OPM is able to maintain pace with the potentially large amount of monitoring data generated. Ideally, the OPM Server should use a Storage Area Network device with I/O spread across several LUNs.
Best practices for DB2 database configuration should also be followed to ensure data and logs are on separate physical I/O devices.
Reducing network hops between the OPM server and the monitored databases allows OPM to read the data more quickly, resulting in increased performance. While this is not always possible nor is it required, there is benefit if you do have the flexibility to physically locate OPM close to the monitored servers.
For more information about capacity planning and deployment of Optim Performance Manager, see the following resources:
Best practices whitepaper: "Deploying Optim Performance Manager in large scale environments"
In this article, learn about best practices for deploying Optim Performance Manager Extended Edition in large scale environments. Although this document is written for V4 of Optim Performance Manager, many of the tips can also be used for the V5.2 release when monitoring DB2 v95 databases.
IBM Optim Performance Manager for DB2 for Linux, UNIX, and Windows Redbook
The following Redbook provides useful information on OPM v5 -- much of the information is also relevant when monitoring DB2 v95 databases in the v53 release.
Monitoring Best Practices:
Monitoring is a balancing act. You need to balance the need for monitoring information with the impact this has on the systems that run your business. OPM helps by providing fine grained control over what monitoring information is collected, and when.
Monitoring Best Practices recommend you collect the right amount of information required to satisfy your business needs for monitoring. Start by collecting a relatively small set of monitoring data and refine as your monitoring needs develop. For example:
How does OPM gather the monitoring data:
OPM uses several native DB2 mechanisms to collect the monitoring data from the data server:
If OPM is configured to collect in-memory metrics then the data is collected by issuing SQL statements. This is the default collection method for data servers >= DB2 V9.7. The SQL statements that OPM executes are cached in the package cache of the monitored data server. This means the cache will need to be slightly larger to maintain a high package cache hit ratio.
If the package cache size (PCKCACHESZ) is configured as AUTOMATIC on the monitored server:
If the package cache size is set to a fixed value on the monitored server:
Depending upon the monitoring profiles selected, OPM will create DB2 event monitors on the monitored server to gather data. The following OPM profiles enable the event monitors listed:
Note: event monitors are read and pruned frequently by OPM, so little data accumulates on the monitored servers.
Event monitors collect their data by inserting information about the event into an event monitor table. The inserts into this event table are logged by db2 at the monitored server. Therefore, there will be an increase in logging activity when OPM creates an event monitor on the monitored server. You must ensure there is adequate free log space on the monitored server to accommodate the increase in logging activity.
Most event monitors collect low volumes of information and will have no impact on the monitored server. For the high volume event monitors, best practices recommend creation of a dedicated tablespace and bufferpool (with a 32K page size) to hold the event monitor data, isolating its impact from the business transactions. High volume event monitors will also require the most additional log space. High volume event monitors can be considered to be:
IBM/Customer Confidential when completed Page