Subsystem Services

Edit online

This topic shows detailed information about Statistics - Subsystem Services.

Statistics - Subsystem Services

The field labels shown in the following sample layout of Statistics - Subsystem Services are described in the following section. 

SUBSYSTEM SERVICES           QUANTITY  /SECOND  /THREAD  /COMMIT
---------------------------  --------  -------  -------  -------
IDENTIFY                         0.00     0.00      N/C     0.00
CREATE THREAD                    0.00     0.00      N/C     0.00
SIGNON                           0.00     0.00      N/C     0.00
TERMINATE                        0.00     0.00      N/C     0.00
ROLLBACK                         0.00     0.00      N/C     0.00

COMMIT PHASE 1                   0.00     0.00      N/C     0.00
COMMIT PHASE 2                   0.00     0.00      N/C     0.00
READ ONLY COMMIT                 0.00     0.00      N/C     0.00
UNITS OF RECOVERY INDOUBT        0.00     0.00      N/C     0.00
UNITS OF REC.INDBT RESOLVED      0.00     0.00      N/C     0.00
SYNCHS(SINGLE PHASE COMMIT)      0.00     0.00      N/C     0.00
QUEUED AT CREATE THREAD          0.00     0.00      N/C     0.00
SUBSYSTEM ALLIED MEMORY EOT      0.00     0.00      N/C     0.00
SUBSYSTEM ALLIED MEMORY EOM      0.00     0.00      N/C     0.00
SYSTEM EVENT CHECKPOINT         17.00     0.09      N/C     0.52

HIGH WATER MARK IDBACK           0.00     0.00      N/C     0.00
HIGH WATER MARK IDFORE           0.00     0.00      N/C     0.00
HIGH WATER MARK CTHREAD          0.00     0.00      N/C     0.00
IDENTIFY

The number of successful connections to Db2 from an allied address space (TSO, BATCH, CICS, IMS, CAF, or UTILITY).

Field Name: Q3STIDEN

CREATE THREAD

The number of successful create thread requests. It does not include DBATs.

A thread is required before an application can use SQL. When established, a thread can have one or more secondary authorization IDs.

A thread is needed to perform any Db2 activity. For example, a thread is needed to run a Db2 utility to perform an IFI request such as READS, or to process a Db2 command such as -DISPLAY THREAD. However, a thread is not created if the command failed because of a syntax error.

Background and Tuning Information

Thread reuse can help improve performance.

The term thread reuse only applies to IMS and CICS attachments. In the case of the TSO attachment facility and the call attachment facility (CAF), threads cannot be reused, because the threads are allocated to the user address space.

Thread reuse should be considered in the following cases:
  • If transaction volume is high:

    High volume transactions should achieve a high percentage of thread reuse. If threads are reused on low volume transactions, the number of threads needed increases because these threads are not automatically terminated by IMS when not being used. This may result in too many idle threads for the level of the Db2 workload. Under CICS, protected threads are terminated after about 45 seconds if no transaction eligible to reuse the thread has been received.

  • If thread creation cost is significant:

    As a rule of thumb, more than 5% of the total CPU cost of transaction processing is considered significant.

The ACQUIRE and RELEASE parameters of BIND should be specified to minimize the thread creation cost, while providing the needed concurrency:
  • If most of the application plan's SQL statements are executed, then ACQUIRE(ALLOCATE) is cheaper than ACQUIRE(USE).
  • If only a small number of the SQL statements are executed, ACQUIRE(USE) becomes cheaper and improves concurrency, because the required resources are only acquired (locked) when the plan actually references (uses) them. An example would be a generalized plan used by many different transactions. It would contain multiple logic paths referencing different tables.

    Note that, when packages are involved, ACQUIRE(USE) is always implicitly used.

  • Concurrency in thread reuse is based on page locking provided by the IS and IX intent locks, whose duration is governed by ACQUIRE and RELEASE of BIND.

    RELEASE(DEALLOCATE) is strongly recommended for thread-reuse transactions to reduce transaction CPU time.

When thread reuse is implemented, monitor the EDM pool. It should be sufficient in size to accommodate expanding plans where the next transaction requires additional plan sections over those that are already part of the plan.

Field Name: Q3STCTHD

This is an exception field.

SIGNON

The number of signons that identified a new user of an existing thread for IMS and CICS.

This field is valid only for CICS and IMS (not valid for TSO, CAF, or UTILITY).

The initial signon does not perform an authorization check because the thread does not exist yet, but a resignon can.

Background and Tuning Information

If the number of signons is greater than the number of create thread occurrences, some threads have been reused. In the case of the TSO attachment facility and the call attachment facility (CAF), there is no sign-on, because the user is identified when the TSO address space is connected.

Field Name: Q3STSIGN

This is an exception field.

TERMINATE

The number of time threads that terminated successfully.

This number does not agree with the create thread count because each level of a thread's access (IDENTIFY, SIGNON, and CREATE THREAD) must be terminated.

Background and Tuning Information

The value of this field is usually greater than the number of create thread occurrences, because it also includes the termination of connections to Db2 (IDENTIFY) and other internal counts.

Field Name: Q3STTERM

ROLLBACK
The number of times a unit of recovery was successfully rolled back. Some reasons for a rollback include:
  • Application program abend
  • Application rollback request
  • Application deadlock on database records
  • Application canceled by operator
  • Thread abend due to resource shortage

This number also includes successfully aborted agents associated with threads that use the Recoverable Resource Manager Services Attach Facility (RRSAF).

Field Name: Q3STABRT

This is an exception field.

COMMIT PHASE 1

The number of successful requests for commit phase 1 in a two-phase commit environment such as CICS or IMS. It includes successfully prepared agents associated with threads that use the Recoverable Resource Manager Services Attach Facility (RRSAF). It does not include successful single-phase commits or distributed two-phase commits.

Background and Tuning Information

IMS and CICS applications use the PREPARE and COMMIT sequence to commit work.

Field Name: Q3STPREP

This is an exception field.

COMMIT PHASE 2

The number of successful commit phase 2 in a two-phase environment such as CICS or IMS. It includes successfully committed agents associated with threads that use the Recoverable Resource Manager Services Attach Facility (RRSAF). It does not include successful single-phase commits or distributed two-phase commits.

Background and Tuning Information

IMS and CICS applications use the PREPARE and COMMIT sequence to commit work. A nonzero value for this field indicates that updates have occurred.

Field Name: Q3STCOMM

READ ONLY COMMIT

The number of read-only commits.

There are occasions when CICS or IMS invokes Db2 when no Db2 resource was altered since the completion of the last commit process. When this occurs, Db2 performs both phases of the two-phase commit during the first commit phase and records that the user or job is read-only in relation to its Db2 processing.

Field Name: Q3STRDON

UNITS OF RECOVERY INDOUBT

The number of indoubt units of recovery.

A unit of recovery is indoubt when a failure occurs after a successful prepare but before a successful commit. The failure can occur in the address space of the application, the transaction manager, Db2, or all of these. IMS and CICS applications use the prepare and commit sequence to commit work. Ideally, this value should be 0.

Field Name: Q3STINDT

UNITS OF REC.INDBT RESOLVED

The number of indoubt units of recovery successfully resolved, either automatically or manually. It includes successful indoubt resolutions for agents associated with threads that use the Recoverable Resource Manager Services Attach Facility (RRSAF).

A unit of recovery is indoubt when a failure occurs after a successful prepare but before a successful commit. This number should equal the number of units of recovery gone indoubt. If it is less, then some indoubt units of recovery might still exist.

Field Name: Q3STRIUR

SYNCHS(SINGLE PHASE COMMIT)

The total number of commits in a single-phase commit environment such as TSO, CAF, or UTILITY. IMS applications use the prepare-and-commit sequence; CICS applications use both the synchronized commit request and the prepare-and-commit sequence to commit work.

Note that DBATs executed on this location are not included. For DBAT statistics, see SINGLE PHASE COMMITS received on the DDF activity block.

Field Name: Q3STSYNC

QUEUED AT CREATE THREAD

The number of create thread requests queued (not including DBATs).

The total number of threads accessing data that can be allocated concurrently is the MAX USERS value on the installation panel DSNTIPE. Requests are queued when the MAX USERS value is exceeded. If no threads are queued during peak hours, the maximum number of threads might be set too high.

Background and Tuning Information

As a rule of thumb about 1% thread queuing is acceptable. When this is appreciably higher, increase the value of MAX USERS on the Db2 install panel DSNTIPE.

The combined maximum allowed for MAX USERS and MAX REMOTE ACTIVE cannot exceed 2000.

Field Name: Q3STCTHW

This is an exception field.

SUBSYSTEM ALLIED MEMORY EOT

The number of times non-Db2 tasks abended while connected to Db2.

Field Name: Q3STMEOT

This is an exception field.

SUBSYSTEM ALLIED MEMORY EOM

The number of times MVS deleted non-Db2 address space while connected to Db2.

Field Name: Q3STMEOM

This is an exception field.

SYSTEM EVENT CHECKPOINT

The number of checkpoints Db2 has taken.

A checkpoint is a point at which Db2 records internal status information to the Db2 log. This information is used in the recovery process if Db2 abends.

Background and Tuning Information

For Statistics reports only: A checkpoint is taken when the specified number of log records have been written. A checkpoint is also taken each time Db2 switches to a new active log data set. If the Statistics reporting period is 30 minutes and the value of this field is 15, then Db2 is taking checkpoints every 2 minutes.

If the data sets are too small or the value for LOGLOAD is too low, checkpoints occur too frequently. As a result, database writes do not perform efficiently. The frequency of Db2 checkpoints can be decreased by increasing the value of the DSNZPARM LOGLOAD (CHECKPOINT FREQ on the Tracing install panel).

Rule of thumb: In a production environment, Db2 should take checkpoints every 10 minutes or so.

The default value for LOGLOAD is 50000. The actual value that you choose is dependent on the volume and nature of the work performed by your Db2 subsystem. It is a trade-off between the performance efficiency of larger numbers and the longer time to restart Db2 when there is an abnormal termination.

Field Name: QWSDCKPT

This is an exception field.

HIGH WATER MARK IDBACK

The maximum number of connections to a single instance from batch or TSO background tasks.

This is a high-water mark.

Field Name: Q3STHWIB

HIGH WATER MARK IDFORE

The maximum number of connections to a single instance from TSO foreground tasks.

This is a high water-mark.

Field Name: Q3STHWIF

HIGH WATER MARK CTHREAD

The highest number of batch CICS, IMS, and TSO tasks (CTHREAD) to a single instance.

This is a high-water mark.

Field Name: Q3STHWCT