下面节选了对 report 理解比较重要的字段，以备忘
大体了解一下
You can obtain OMEGAMON reports of accounting data in long or short format
and in various levels of detail.
The examples of OMEGAMON reports in this information are based on the default
formats, which might have been modified for your installation. Furthermore, the
OMEGAMON reports have been reformatted or modified for this publication.
Refer to OMEGAMON Report Reference for an exact description of each report. You
can also time results for nested activities such as triggers, stored procedures, and
user-defined functions.
Only class 1 of the accounting trace is needed for a report of information by plan.
Classes 2 and 3 are recommended for additional information. Classes 7 and 8 are
needed to give information by package or DBRM.
Use the OMEGAMON accounting report, long format, when an application seems
to have a problem, and you need very detailed analysis
Class 1 elapsed time
Compare this with the CICS, IMS, WebSphere, or distributed application transit
times:
In CICS, you can use CICS Performance Analyzer to find the attach and detach
times; use this time as the transit time.
In IMS, use the PROGRAM EXECUTION time reported in IMS Performance
Analyzer.
Differences between the CICS, IMS, WebSphere, or distributed application times
and the DB2 accounting times arise mainly because the DB2 times do not include:
Time before the first SQL statement, which for a distributed application includes
the inbound network delivery time
DB2 create thread
DB2 terminate thread
For a distributed application, the time to deliver the response to a commit if
database access thread pooling is used
Differences can also arise from thread reuse in CICS, IMS, WebSphere, or
distributed application processing or through multiple commits in CICS. If the
class 1 elapsed time is significantly less than the CICS or IMS time, check the
report from Tivoli Decision Support for z/OS, IMS Performance Analyzer, or an
equivalent reporting tool to find out why. Elapsed time can occur:
v In DB2, during sign-on, create, or terminate thread
v Outside DB2, during CICS or IMS processing
Not-in-DB2 time
This time is the calculated difference between the class 1 and the class 2 elapsed
time. This value is the amount of time spent outside of DB2, but within the DB2
accounting interval. A lengthy time can be caused by thread reuse, which can
increase class 1 elapsed time, or a problem in the application program, CICS, IMS,
or the overall system.
For a distributed application, not-in-DB2 time is calculated with this formula:
Not_in_DB2 time = A - (B + C + (D - E))
Where the variables have the following values:
A Class 1 elapsed time
B Class 2 non-nested elapsed time
C Class 1 non-nested elapsed time of any stored procedures, user-defined
functions, or triggers
D Class 1 non-nested CPU time
E Class 2 non-nested CPU time
The calculated not-in-DB2 time might be zero. Furthermore, this time calculation is
only an estimate. A primary factor that is not included in the equation is the
amount of time that requests wait for CPU resources while executing within the
DDF address space. To determine how long requests wait for CPU resources, look
at the NOT ACCOUNT field. The NOT ACCOUNT field shows the time that
requests wait for CPU resources while a distributed task is inside DB2.
Lock/latch suspension time
This shows contention for DB2 and IRLM resources. If contention is high, check
the locking summary section of the report, and then proceed with the locking
reports.
Synchronous I/O suspension time
This is the total application wait time for synchronous I/Os. It is the total of
database I/O and log write I/O.
If the number of synchronous read or write I/Os is higher than expected, check
for:
A change in the access path to data. First, check getpage count. If it has
significantly increased, then a change in access path must have occurred.
However, if the getpage count remained about the same, but the number of I/Os
increased significantly, the problem is not an access path change. If you have
data from accounting trace class 8, the number of synchronous and
asynchronous read I/Os is available for individual packages. Determine which
package or packages have unacceptable counts for synchronous and
asynchronous read I/Os. Activate the necessary performance trace classes for the
OMEGAMON SQL activity reports to identify the SQL statement or cursor that
is causing the problem. If you suspect that your application has an access path
problem, consider using IBM Optimization Service Center for DB2 for z/OS and
DB2 EXPLAIN.
A lower than expected buffer pool hit ratio. You can improve the ratio by tuning
the buffer pool. Look at the number of synchronous reads in the buffer pool that
are associated with the plan, and look at the related buffer pool hit ratio. If the
buffer pool size and the buffer pool hit ratio for random reads is small, consider
increasing the buffer pool size. By increasing the buffer pool size, you might
reduce the amount of synchronous database I/O and reduce the synchronous
I/O suspension time.
v A change to the catalog statistics, or statistics that no longer match the data.
v Changes in the application. Check the “SQL ACTIVITY” section and compare
with previous data. Some inserts might have changed the amount of data. Also,
check the names of the packages or DBRMs being executed to determine if the
pattern of programs being executed has changed.
v Pages might be out of order so that sequential detection is not used, or data
might have been moved to other pages. Run the REORG utility in these
situations.
A system-wide problem in the database buffer pool. You can also use
OMEGAMON DB2 Buffer Pool Analyzer (DB2 BPA) or OMEGAMON DB2
Performance Expert, which contains the function of DB2 BPA, to manage and
optimize buffer pool activity.
A RID pool failure.
v A system-wide problem in the EDM pool.
If I/O time is greater than expected, and not caused by more read I/Os, check for:
v Synchronous write I/Os. (You can also use OMEGAMON DB2 Buffer Pool
Analyzer (DB2 BPA) or OMEGAMON DB2 Performance Expert, which contains
the function of DB2 BPA, to manage and optimize buffer pool activity)
I/O contention. In general, each synchronous read I/O typically takes from 5 to
20 milliseconds, depending on the disk device. This estimate assumes that no
prefetch or deferred write I/Os exist on the same device as the synchronous
I/Os.
v An increase in the number of users, or an increase in the amount of data. Also,
drastic changes to the distribution of the data can cause the problem
Processor resource consumption
The problem might be caused by DB2 or IRLM traces, a change in access paths, or
an increase in the number of users. In the OMEGAMON accounting report, DB2
processor resource consumption is indicated in the field for class 2 CPU TIME
(C).
Other read suspensions
The accumulated wait time for read I/O done under a thread other than this one.
It includes time for:
v Sequential prefetch
v List prefetch
v Dynamic prefetch
v Synchronous read I/O performed by a thread other than the one being reported
Generally, an asynchronous read I/O for sequential prefetch or dynamic prefetch
takes about 0.035 to 0.4 milliseconds per page. List prefetch takes about the same
time on the low end but can, on the high end, take 5 to 10 milliseconds per page.
Other write suspensions
The accumulated wait time for write I/O done under a thread other than this one.
It includes time for:
v Asynchronous write I/O
v Synchronous write I/O performed by a thread other than the one being reported
As a guideline, an asynchronous write I/O takes 0.1 to 2 milliseconds per page.
Service task suspensions
The accumulated wait time from switching synchronous execution units, by which
DB2 switches from one execution unit to another. The most common contributors
to service task suspensions are:
v Wait for phase 2 commit processing for updates, inserts, and deletes (UPDATE
COMMIT). You can reduce this wait time by allocating the DB2 primary log on a
faster disk. You can also help to reduce the wait time by reducing the number of
commits per unit of work.
v Wait for OPEN/CLOSE service task (including HSM recall). You can minimize
this wait time by using two strategies. If DSMAX is frequently reached, increase
DSMAX. If DSMAX is not frequently reached, change CLOSE YES to CLOSE NO
on data sets that are used by critical applications.
v Wait for SYSLGRNG recording service task.
v Wait for data set extend/delete/define service task (EXT/DEL/DEF). You can
minimize this wait time by defining larger primary and secondary disk space
allocation for the table space.
v Wait for other service tasks (OTHER SERVICE).On DB2 requester systems, the
amount of time waiting for requests to be returned from either VTAM or
TCP/IP, including time spent on the network and time spent handling the
request in the target or server systems (OTHER SERVICE).
In the OMEGAMON accounting report, the total of this information is reported in
the field SER.TASK SWTCH (F). The field is the total of the five fields that
follow it. If several types of suspensions overlap, the sum of their wait times can
exceed the total clock time that DB2 spends waiting. Therefore, when service task
suspensions overlap other types, the wait time for the other types of suspensions is
not counted.
Archive log mode (QUIESCE)
The accumulated time the thread was suspended while processing ARCHIVE LOG
MODE(QUIESCE). In the OMEGAMON accounting report, this information is
reported in the field ARCH.LOG (QUIES) (G).
Archive log read suspension
This is the accumulated wait time the thread was suspended while waiting for a
read from an archive log on tape. In the OMEGAMON accounting report, this
information is reported in the field ARCHIVE LOG READ (H).
Drain lock suspension
The accumulated wait time the thread was suspended while waiting for a drain
lock. If this value is high, check the installation options that relate to wait times,
and consider running the OMEGAMON locking reports for additional detail. In
the OMEGAMON accounting report, this information is reported in the field
DRAIN LOCK (I).
Claim release suspension
The accumulated wait time the drainer was suspended while waiting for all claim
holders to release the object. If this value is high, check the installation options for
wait times, and consider running the OMEGAMON locking reports for additional
details.
In the OMEGAMON accounting report, this information is reported in the field
CLAIM RELEASE (J).
Page latch suspension
This field shows the accumulated wait time because of page latch contention. As
an example, when the RUNSTATS and COPY utilities are run with the
SHRLEVEL(CHANGE) option, they use a page latch to serialize the collection of
statistics or the copying of a page. The page latch is a short duration “lock”.
Not-accounted-for DB2 time
Usually the DB2 Class 2 Not Accounted time is very small or negligible. It
represents time that DB2 is unable to account for. The DB2 accounting class 2
elapsed time that is not recorded as class 2 CPU time or class 3 suspensions. If you
see significant DB2 Class 2 Not Accounted time, it could be because one of the
following reasons:
v Too much detailed online tracing, or problems with some vendor performance
monitors. This situation is usually the primary cause of high not-accounted-for
time on systems that are not CPU-constrained.
In a non-data sharing environment, running in a very high CPU utilization
environment and waiting for CPU cycles, especially with lower dispatching
Waiting for return from requests to be returned from VTAM or TCP/IP
v Reading the instrumentation facility interface (IFI) log.
v In very I/O intensive environments, the Media Manager might be running out
of request blocks.
v Waiting for package accounting.
v A PREPARE statement which is not found in the dynamic statement cache.
v Data set open contention related to PCLOSET being too small.
v Gathering RMF interval data set statistics.
v DB2 internal suspend and resume looping when several threads are waiting for
the same resource. This case is very rare.
v Time spent waiting for parallel tasks to complete (when query parallelism is
