Thread types
The Db2 thread or, for a thread in reuse, the part of it that is between two consecutive signons or resignon, is the basic unit of reporting for the Accounting report set.
Thread categories
OMEGAMON for Db2 PE uses the following categorization of Db2 threads:
- Allied thread
- An
allied thread:
- Originates at the local Db2 subsystem and can access data at a remote Db2 subsystem.
- Does not involve distributed activity, that is, it is not initiated by a remote location and does not request data from another location.
- Can be filtered for Accounting by selecting the OMEGAMON for Db2 PE identifier THREADTYPE with a value of ALLIED. The Accounting report ordered by THREADTYPE shows ALLIED as an individual criterion.
The Accounting record that represents an allied thread consists of the following set of data, which is called non-DDF (Distributed Data Facility) data:- Identification of the thread
- General timing
- SQL and RID list usage
- Query parallelism
- Buffer pool activity
- Group buffer pool activity
- Data sharing locking
- Stored procedures
- Data capture
- Locking activity
- Packages and DBRMs executed
- Resource limit facility data
- Allied-distributed thread
- An allied-distributed thread:
- Requests work from remote server locations.
- Is not initiated by a remote location.
- Can be filtered for Accounting by selecting the OMEGAMON for Db2 PE identifier THREADTYPE with a value of ALLIED_DIST. The Accounting report ordered by THREADTYPE can show ALLDDIST as an individual criterion.
- Database access thread (DBAT)
- A DBAT thread:
- Accesses data at the local subsystem on behalf of a remote subsystem.
- Can be filtered for Accounting by selecting the OMEGAMON for Db2 PE identifier THREADTYPE with a
value of DBAT. The Accounting record that represents a DBAT consists of:
- Non-DDF data
- DDF data for the requester location
- Also includes DBAT-distributed threads that are initiated by a
requester location and executed by the server location that in turn requests data from
another server location. The Accounting report ordered by THREADTYPE can show one or several of the following criterion:
- DBAT
- Indicates accumulated data of threads that are initiated, created, and performing work on behalf of a remote (requester) location.
- DBATDP
- Indicates accumulated data of DBAT duplicate threads.
- DBATDIST
- Indicates accumulated data of DBAT distributed threads that are initiated by a requester location and executed by the server location that in turn requests data from another server location.
- DBATDICP
- Indicates accumulated data of DBAT distributed and copy threads.
- DBATDIDP
- Indicates accumulated data of DBAT distributed and duplicate threads.
For example, when location A uses DRDA to request data at location B and, in the same unit of work, accesses data at location C (using Db2 private protocol), the thread created at location A is an allied-distributed thread, the thread created at location B is a DBAT-distributed thread. The thread created at location C is a DBAT.
The Accounting record that represents a DBAT-distributed thread consists of:- Non-DDF data
- DDF data for the requester location
- One block of DDF data for each participating server location
Thread types reported by ORDER
The following terms can help you to understand the concepts of the different thread types and merged processing:
- Nondistributed transaction
- A nondistributed transaction for Accounting:
- Is initiated by Db2 and performed at one location without interaction with other locations. For example, if an allied thread is not reused, it represents a nondistributed transaction. If it is reused, a nondistributed transaction is a Db2 activity between two signons.
- Can be filtered by specifying the INCLUDE or EXCLUDE subcommand
options with the OMEGAMON for Db2
Performance Expert identifier THREADTYPE using
a value of ALLIED or DBAT. As a result the Accounting report ordered
by THREADTYPE can show a thread type of ALLIED, DBAT, or DBATDP. Note: The OMEGAMON for Db2 Performance Expert identifier DBAT also covers the distributed transactions.
- Distributed transaction
- A distributed transaction for Accounting:
- Is initiated by Db2 at one (requester) location and performed at one or more remote (server) locations.
- Consists of a local activity that is represented by an allied-distributed thread, and in case of a loopback from a DBAT, remote activity that is represented by one or more DBATs. Therefore, a distributed transaction requires Accounting records for the allied-distributed thread and all corresponding DBATs.
- Can be filtered by specifying the INCLUDE or EXCLUDE subcommand
options with the OMEGAMON for Db2
Performance Expert identifier THREADTYPE using
a value of ALLIED-DIST or DBAT. Note: The OMEGAMON for Db2 Performance Expert identifier DBAT also covers the nondistributed transactions.
The Accounting report ordered by THREADTYPE can show one or several of the following thread types that are distributed transactions:
- ALLDDIST
- Indicates accumulated data of threads initiated by Db2 and that request data from one or more server locations.
- DBATDIST
- Indicates accumulated data of DBAT distributed threads that are initiated by a requester location and executed by the server location that in turn requests data from another server location.
- DBATDICP
- Indicates accumulated data of DBAT distributed and copy threads.
- DBATDIDP
- Indicates accumulated data of DBAT distributed and duplicate threads.
Activity location
Reports and traces are location-oriented. They show activity that is performed at one or more locations. For a given location, the following information is shown:
- The nondistributed transactions, in other words, the allied threads at that location
- The local activity of distributed transactions that originate at that location, in other words, the allied-distributed threads from that location without the corresponding DBATs at other locations
- The remote activity at that location as part of distributed transactions requested from other locations, in other words, the DBATs at that location
Multi-site or single-site reports
Reports and traces can be single-site or multi-site:
- Single-site reports and traces present Accounting data for one location. You can obtain a single-site report or trace by processing input data that only contains records from a single location or by specifying a single location with the INCLUDE or EXCLUDE subcommand options.
- Multi-site reports and traces present Accounting data for more than one location. The data is arranged in alphabetical order by location name.