Use the series of predefined situations associated with the Detailed
Thread Exception workspace to begin monitoring your system immediately or
as templates for creating your own situations.
OMEGAMON XE for DB2 PE includes
a series of predefined situations associated with the Detailed Thread Exception
workspace. You can use these situations to begin monitoring almost immediately,
or as templates for creating your own situations.
The names, descriptions,
logic, and threshold values for the situations follow.
KDP_ARCM_Critical monitors
the status of thread backout processing, detecting a critical condition when
the thread backout processing is waiting for an archive tape mount. DB2 requires
the archive tape mount during abort processing to backout changes made in
the current unit of recovery. The thread does not do any processing until
the tape is mounted. It holds DB2 resources until the abort request is complete.
The situation's formula is:
KDP_Thread_Exceptions.Archive_Tape_Wait EQ TRUE
KD5_ARCM_Warning monitors
the status of thread backout processing, detecting a warning condition when
the thread backout processing is waiting for an archive tape mount. DB2 requires
the archive tape mount during abort processing to backout changes made in
the current unit of recovery. The thread does not do any processing until
the tape is mounted. It holds DB2 resources until the abort request is complete.
The situation's formula is:
KD5_Thread_Exceptions.Archive_Tape_Wait EQ TRUE
KDP_COMT_Critical monitors
the ratio of updates to commits for the thread, detecting a critical condition
when the ratio reaches 100. The situation's formula is:
KDP_Thread_Exceptions.Commit_Ratio GE 100
KDP_COMT_Warning monitors the ratio of updates to commits for the thread, detecting a warning
condition when the ratio is in the range of 80% to 100%. The situation's formula
is:
KDP_Thread_Exceptions.Commit_Ratio GE 80
AND
KDP_Thread_Exceptions.Commit_Ratio LT 100
KDP_CTHD_Critical monitors the state of an application, detecting a critical
condition when an application is waiting for DB2 to create a thread. This
condition arises when the system's maximum thread limit is reached. The situation's
formula is:
KDP_Thread_Exceptions.Thread_Create_Wait EQ TRUE
KD5_CTHD_Warning monitors
the state of an application, detecting a warning condition when an application
is waiting for DB2 to create a thread. This condition arises when the system's
maximum thread limit is reached. The situation's formula is:
KD5_Thread_Exceptions.Thread_Create_Wait EQ TRUE
KDP_DWAT_Critical monitors the period of time a distributed allied thread has been waiting
for a response to a remote SQL request. A critical condition is detected when
the period reaches ten seconds. The situation's formula is:
KDP_Thread_Exceptions.Wait_Time_Distributed_Query GE 00:00:10.000
KD5_DWAT_Warning monitors the period of time a distributed
allied thread has been waiting for a response to a remote SQL request. A warning
condition is detected when the period is in the range of eight to ten seconds.
The situation's formula is:
KD5_Thread_Exceptions.Wait_Time_Distributed_Query GE 00:00:08.000
AND
KD5_Thread_Exceptions.Wait_Time_Distributed_Query LT 00:00:10.000
KDP_ETIM_Critical monitors the elapsed time for a DB2 thread
(from sign-on or create thread). A critical condition is detected when the
elapsed time reaches ten minutes. The situation's formula is:
KDP_Thread_Exceptions.Elapsed_Time GE 00:10:00
KD5_ETIM_Warning monitors the elapsed time for a DB2 thread (from sign-on or create thread).
A warning condition is detected when the elapsed time ranges from eight to
ten minutes. The situation's formula is:
KD5_Thread_Exceptions.Elapsed_Time GE 00:08:00
AND
KD5_Thread_Exceptions.Elapsed_Time LT 00:10:00
KDP_GETP_Critical monitors the status of getpage requests.
A critical condition is detected when the ratio of logical page read (getpage)
requests to physical page read (read I/O) requests is less than the specified
threshold of 15. The default threshold for GETP is specified as an integer,
where one equals 0.1 getpages to read I/Os. The situation's formula is:
KDP_Thread_Exceptions.Getpage_Ratio LT 15.0
KD5_GETP_Warning monitors the status of getpage requests. A warning condition
is detected when the ratio of logical page read (getpage) requests to physical
page read (read I/O) requests is in the range of 18 to 15. The default threshold
for GETP is specified as an integer, where one equals 0.1 getpages to read
I/Os. The situation's formula is:
KD5_Thread_Exceptions.Getpage_Ratio GE 15.0
AND
KD5_Thread_Exceptions.Getpage_Ratio LT 18.0
KDP_IDBC_Critical monitors the amount of CPU time used by
DB2 to process a thread. A critical condition is detected when the CPU time
reaches the specified threshold of one minute ten seconds. The situation's
formula is:
KDP_Thread_Exceptions.DB2_CPU_Used GE 00:01:10.000
KD5_IDBC_Warning monitors
the amount of CPU time used by DB2 to process a thread. A warning condition
is detected when the CPU time ranges from 56 seconds to one minute ten seconds.
The situation's formula is:
KD5_Thread_Exceptions.DB2_CPU_Used GE 00:00:56.000
AND
KD5_Thread_Exceptions.DB2_CPU_Used LT 00:01:10.000
KDP_IDBT_Critical provides information about the length of
time DB2 has been processing this thread. A critical condition is detected
when the length of time that DB2 has been processing a thread is greater than
five seconds. The situation's formula is:
KDP_Thread_Exceptions.DB2_Elapsed_Time GE 00:00:05.0
KD5_IDBT_Warning provides information about the length of time DB2 has been processing this
thread. A warning condition is detected when the length of time that DB2 has
been processing a thread is in the range of four to five seconds. The situation's
formula is:
KD5_Thread_Exceptions.DB2_Elapsed_Time GE 00:00:04.0
AND
KD5_Thread_Exceptions.DB2_Elapsed_Time LT 00:00:05.0
KDP_INDB_Critical provides information about individual threads
that are in INDOUBT status. These threads may cause DB2 resources to be unavailable
to other active threads until either restart or RECOVER INDOUBT processing
occurs. A critical condition is detected when individual threads are in doubt.
The situation's formula is:
KDP_Thread_Exceptions.Indoubt EQ TRUE
KD5_INDB_Warning provides
information about individual threads that are in INDOUBT status. These threads
may cause DB2 resources to be unavailable to other active threads until either
restart or RECOVER INDOUBT processing occurs. A warning condition is detected
when individual threads are in doubt. The situation's formula
is:
KD5_Thread_Exceptions.Indoubt EQ TRUE
KDP_LKUS_Critical monitors
the number of locks owned by an individual thread. A critical condition is
detected when the percentage of page locks owned by an active thread to the
total allowable number of held page locks reaches 80%. The situation's formula
is:
KDP_Thread_Exceptions.Lock_Percentage GE 80.0
KDP_LKUS_Warning monitors
the number of locks owned by an individual thread. A warning condition is
detected when the percentage of page locks owned by an active thread to the
total allowable number of held page locks is in the range of 64% to 80%. The
situation's formula is:
KDP_Thread_Exceptions.Lock_Percentage GE 64.0
AND
KDP_Thread_Exceptions.Lock_Percentage LT 80.0
KDP_PGUP_Critical monitors the number of page update requests
per second made by a thread.
The update count reflected in this exception
is incremented each time a row in a page is updated. Updated pages are not
necessarily written at commit, but rather later, asynchronously as determined
by the DB2 deferred write algorithm. There is no direct, immediate relationship,
therefore, between page updates and page writes.
The counters that DB2
maintains for this activity are updated throughout the life of the thread,
and are reset at DB2 sign-on if the thread is reused. A critical condition
is detected when the number of row updates per second on behalf of a thread
reaches ten. The situation's formula is:
KDP_Thread_Exceptions.Page_Update_Rate GE 10.0
KDP_PGUP_Warning monitors
the number of page update requests per second made by a thread.
The
update count reflected in this exception is incremented each time a row in
a page is updated. Updated pages are not necessarily written at commit, but
asynchronously as determined by the DB2 deferred write algorithm. There is
no direct, immediate relationship between page updates and page writes.
The
counters that DB2 maintains for this activity are updated throughout the life
of the thread, and are reset at DB2 sign-on if the thread is reused. A warning
condition is detected when the number of row updates per second on behalf
of a thread is in the range of eight to ten. The situation's formula is:
KDP_Thread_Exceptions.Page_Update_Rate GE 8.0
AND
KDP_Thread_Exceptions.Page_Update_Rate LT 10.0
KDP_PREF_Critical monitors
read sequential prefetch activity.
Unlike normal read I/O, sequential
prefetch read I/O is performed asynchronously with the user's request. It
provides a read-ahead capability. A single sequential prefetch I/O results
in multiple pages being read. Threads with excessive sequential prefetch rates
may cause a negative impact on overall DB2 performance.
The counters
which DB2 maintains for this activity are updated throughout the life of the
thread, and are reset during DB2 sign-on if the thread is reused. A critical
condition is detected when the number of sequential prefetch requests reaches
ten per second. The situation's formula is:
KDP_Thread_Exceptions.Prefetch_Rate GE 10.0
KDP_PREF_Warning monitors
read sequential prefetch activity.
Unlike normal read I/O, sequential
prefetch read I/O is performed asynchronously with the user's request. It
provides a read-ahead capability. A single sequential prefetch I/O results
in multiple pages being read. Threads with excessive sequential prefetch rates
may cause a negative impact on overall DB2 performance.
The counters
which DB2 maintains for this activity are updated throughout the life of the
thread, and are reset during DB2 sign-on if the thread is reused. A warning
condition is detected when the number of sequential prefetch requests is in
the range of eight to ten per second. The situation's formula is:
KDP_Thread_Exceptions.Prefetch_Rate GE 8.0
AND
KDP_Thread_Exceptions.Prefetch_Rate LT 10.0
KDP_RCPU_Critical monitors
the amount of CPU time being used by a distributed database access thread
at the remote DB2 location. A critical condition is detected when the amount
of CPU time used by a database access thread at a remote DB2 location reaches
fifty seconds. The situation's formula is:
KDP_Thread_Exceptions.Distributed_CPU_Seconds GE 00:00:50.000
KD5_RCPU_Warning monitors the amount of CPU time being used by a distributed database access
thread at the remote DB2 location. A warning condition is detected when the
amount of CPU time used by a database access thread at a remote DB2 location
is in the range of forty to fifty seconds. The situation's formula is:
KD5_Thread_Exceptions.Distributed_CPU_Seconds GE 00:00:40.000
AND
KD5_Thread_Exceptions.Distributed_CPU_Seconds LT 00:00:50.000
KDP_RELM_Critical monitors
the ratio of the resource limit high water mark (CPU seconds) to the current
resource limit. A critical condition is detected when the ratio of the resource
limit high water mark (CPU seconds) to the resource limit in effect (CPU seconds)
reaches 80%. The situation's formula is:
KDP_Thread_Exceptions.Resource_Limit_Percent GE 80.0
KDP_RELM_Warning monitors the ratio of the resource limit high water mark (CPU seconds) to
the current resource limit. A warning condition is detected when the ratio
of the resource limit high water mark (CPU seconds) to the resource limit
in effect (CPU seconds) is in the range of 64% to 80%. The situation's formula
is:
KDP_Thread_Exceptions.Resource_Limit_Percent GE 64.0
AND
KDP_Thread_Exceptions.Resource_Limit_Percent LT 80.0
KDP_RIO_Critical monitors the thread synchronous read I/Os
rate.
Generally, this exception indicates excessive physical read I/O
on behalf of a thread. While a single SELECT may return a limited number of
rows, the pages searched may be enormous. I/O may be caused by access path
selection changes which occurred because of object changes (indexes dropped
or no longer clustered), or by inadvertent use of stage 2 predicates. It might
result from the fact that the SQL is a set-oriented language, that operates
on sets of data, rather than on individual rows (records).
The counters
which DB2 maintains for this activity are updated throughout the life of the
thread, and are reset during DB2 sign-on if the thread is reused. A critical
condition is detected when the physical read I/O rate per second on behalf
of a thread reaches ten. The situation's formula is:
KDP_Thread_Exceptions.Read_I/O_Rate GE 10.0
KD5_RIO_Warning monitors the thread synchronous read I/Os rate.
Generally, this exception
indicates excessive physical read I/O on behalf of a thread. While a single
SELECT may return a limited number of rows, the pages searched may be enormous.
I/O may be caused by access path selection changes which occurred because
of object changes (indexes dropped or no longer clustered), or by inadvertent
use of stage 2 predicates. It might result from the fact that the SQL is a
set-oriented language, that operates on sets of data, rather than on individual
rows (records).
The counters which DB2 maintains for this activity are
updated throughout the life of the thread, and are reset during DB2 sign-on
if the thread is reused. A warning condition is detected when the physical
read I/O rate per second on behalf of a thread is in the range of eight to
ten. The situation's formula is:
KD5_Thread_Exceptions.Read_I/O_Rate GE 8.0
AND
KD5_Thread_Exceptions.Read_I/O_Rate LT 10.0
KDP_TCPU_Critical monitors the CPU rate (percent) of active
threads.
For non-CICS threads, this is the CPU rate of the address space
from which the thread originates. It includes both TCB and SRB time. For CICS
threads, this is the CPU rate attributable to the thread originating from
the CICS connection. It includes only TCB time incurred by the thread.
This
situation limits its analysis of CPU use to DB2 connections that contain active
threads. It does not report CPU use for connections with no active threads.
A critical condition is detected when CPU utilization for an address space
that has DB2 connections and threads reaches 20%. The situation's formula
is:
KDP_Thread_Exceptions.CPU_Utilization GE 20.0
KD5_TCPU_Warning monitors
the CPU rate (percent) of active threads.
For non-CICS threads, this
is the CPU rate of the address space from which the thread originates. It
includes both TCB and SRB time. For CICS threads, this is the CPU rate attributable
to the thread originating from the CICS connection. It includes only TCB
time incurred by the thread.
This situation limits its analysis of CPU
use to DB2 connections that contain active threads. It does not report CPU
use for connections with no active threads. A warning condition is detected
when CPU utilization for an address space that has DB2 connections and threads
is in the range of 16% to 20%. The situation's formula is:
KD5_Thread_Exceptions.CPU_Utilization GE 16.0
AND
KD5_Thread_Exceptions.CPU_Utilization LT 20.0
KDP_TRCV_Critical monitors the amount of data received by
distributed threads from a remote DB2 subsystem. A critical condition is detected
when the amount of data received by a requestor (allied) or server (distributed)
DB2 thread in response to SQL requests reaches 1000 kilobytes. The situation's
formula is:
KDP_Thread_Exceptions.Distributed_Receive_Bytes GE 1000
KD5_TRCV_Warning monitors
the amount of data received by distributed threads from a remote DB2 subsystem.
A warning condition is detected when the amount of data received by a requestor
(allied) or server (distributed) DB2 thread in response to SQL requests is
in the range of 800 to 1000 kilobytes. The situation's formula is:
KD5_Thread_Exceptions.Distributed_Receive_Bytes GE 800
AND
KD5_Thread_Exceptions.Distributed_Receive_Bytes LT 1000
KDP_TSND_Critical monitors
the amount of data sent by distributed threads to a remote DB2 subsystem.
A critical condition is detected when the amount of data sent by a requestor
(allied) or server (distributed) DB2 thread in response to SQL requests reaches
1000 kilobytes. The situation's formula is:
KDP_Thread_Exceptions.Distributed_Send_Bytes GE 1000
KD5_TSND_Warning monitors the amount of data sent by distributed threads to a remote DB2
subsystem. A warning condition is detected when the amount of data sent by
a requestor (allied) or server (distributed) DB2 thread in response to SQL
requests is in the range of 800 to 1000 kilobytes. The situation's formula
is:
KD5_Thread_Exceptions.Distributed_Send_Bytes GE 800
AND
KD5_Thread_Exceptions.Distributed_Send_Bytes LT 1000
KDP_WCLM_Critical indicates when a thread has been waiting
for more than the specified length of time for a resource to be drained of
claimers. The default threshold is 60 seconds. The situation's formula is:
KDP_Thread_Exceptions.Wait_Time_Drain_Claims GE 60.000
KD5_WCLM_Warning cautions that a thread has been waiting for
more than the specified length of time for a resource to be drained of claimers.
The default warning range is 48 to 60 seconds. The situation's formula is:
KD5_Thread_Exceptions.Wait_Time_Drain_Claims GE 48.000
AND
KD5_Thread_Exceptions.Wait_Time_Drain_Claims LT 60.000
KDP_WDLK_Critical monitors
the state of a thread waiting to acquire a drain lock. A critical condition
is detected when the length of time to acquire a drain lock reaches 60 seconds.
The situation's formula is:
KDP_Thread_Exceptions.Wait_Time_Drain_Lock GE 60.000
KD5_WDLK_Warning monitors
the state of a thread waiting to acquire a drain lock. A critical condition
is detected when the length of time to acquire a drain lock is in the range
of 48 to 60 seconds. The situation's formula is:
KD5_Thread_Exceptions.Wait_Time_Drain_Lock GE 48.000
AND
KD5_Thread_Exceptions.Wait_Time_Drain_Lock LT 60.000
KDP_WGLK_Critical monitors the state of threads waiting to
acquire a global lock. A critical condition is detected when a thread has
been waiting for 60 seconds to acquire a global lock in a data sharing environment.
The situation's formula is:
KDP_Thread_Exceptions.Wait_Time_Global_Lock GE 60.000
KD5_WGLK_Warning monitors
the state of threads waiting to acquire a global lock. A warning condition
is detected when a thread has been waiting in the range of 48 to 60 seconds
to acquire a global lock in a data sharing environment. The situation's formula
is:
KD5_Thread_Exceptions.Wait_Time_Global_Lock GE 48.000
AND
KD5_Thread_Exceptions.Wait_Time_Global_Lock LT 60.000
KDP_WLGQ_Critical indicates that a thread has been waiting
for more than the specified length of time for an ARCHIVE LOG MODE(QUIESCE)
command to complete. A critical condition is detected when the amount of time
that a thread has been suspended because of ARCHIVE LOG MODE (QUIESCE) reaches
60 seconds. The situation's formula is:
KDP_Thread_Exceptions.Wait_Time_Log_Queue GE 60.000
KD5_WLGQ_Warning indicates
that a thread has been waiting for more than the specified length of time
for an ARCHIVE LOG MODE(QUIESCE) command to complete. A warning condition
is detected when the amount of time that a thread has been suspended because
of ARCHIVE LOG MODE (QUIESCE) ranges from 48 to 60 seconds. The situation's
formula is:
KD5_Thread_Exceptions.Wait_Time_Log_Queue GE 48.000
AND
KD5_Thread_Exceptions.Wait_Time_Log_Queue LT 60.000
KDP_WSPS_Critical indicates that a thread has been waiting
for more than the specified length of time for the stored procedures address
space to become available in order for a stored procedure to be scheduled.
A critical condition is detected when the amount of time a thread has been
waiting for an available TCB to schedule a stored procedure reaches 60 seconds.
The situation's formula is:
KDP_Thread_Exceptions.Wait_Time_Procedure GE 60.000
KD5_WSPS_Warning indicates
that a thread has been waiting for more than the specified length of time
for the stored procedures address space to become available in order for a
stored procedure to be scheduled. A warning condition is detected when the
amount of time a thread has been waiting for an available TCB to schedule
a stored procedure ranges from 48 to 60 seconds. The situation's formula is:
KD5_Thread_Exceptions.Wait_Time_Procedure GE 48.000
AND
KD5_Thread_Exceptions.Wait_Time_Procedure LT 60.000
KDP_WSRV_Critical indicates
that a thread has been waiting for more than the specified length of time
for a DB2 service. DB2 service waits include open/close data set, SYSLGRNG
update, DFHSM recall, Dataspace Manager services, and define/delete/extend
data set. A critical condition is detected when the amount of time a thread
has been waiting for a DB2 service to complete reaches 30 seconds. The situation's
formula is:
KDP_Thread_Exceptions.Wait_Time_Service GE 00:00:30.000
KD5_WSRV_Warning indicates
that a thread has been waiting for more than the specified length of time
for a DB2 service. DB2 service waits include open/close data set, SYSLGRNG
update, DFHSM recall, Dataspace Manager services, and define/delete/extend
data set. A warning condition is detected when the amount of time a thread
has been waiting for a DB2 service to complete ranges from 24 to 30 seconds.
The situation's formula is:
KD5_Thread_Exceptions.Wait_Time_Service GE 00:00:24.000
AND
KD5_Thread_Exceptions.Wait_Time_Service LT 00:00:30.000
KDP_WTRE_Critical monitors a thread's wait time for a resource.
A critical condition is detected when a thread has been waiting for 60 seconds.
The situation's formula is:
KDP_Thread_Exceptions.Wait_Time_Resource GE 60.000
KDP_WTRE_Warning monitors
a thread's wait time for a resource. A critical condition is detected when
a thread has been waiting between 48 and 60 seconds. The situation's formula
is:
KDP_Thread_Exceptions.Wait_Time_Resource GE 48.000
AND
KDP_Thread_Exceptions.Wait_Time_Resource LT 60.000