How DBATs process remote connections
Db2 uses distributed database access threads (DBATs) to process requests through a network for distributed clients that access data in a Db2 for z/OS® server.
Db2 uses DBATs to process the following requests from distributed clients:
- Accept new connections
- Process transaction requests
- Terminate connections
For more information, see How Db2 allocates threads.
Inactive connections support
Inactive connections support (sometimes called "type-2 inactive threads") operates by separating the distributed connections (in DDF) from the threads (DBATs) that do the work (in the ssnmDBM1 address space). A pool of DBATs is created for use by inbound DRDA connections. A connection makes temporary use of a DBAT to execute a UOW and releases it back to the pool at a commit or rollback, for another connection to use. A DBAT is in-use when it is processing requests from client connections within a unit of work (UOW).
The result is that a given number of inbound connections require a much smaller number of DBATs to execute the work within Db2. Each DDF connection uses only approximately 7.5 K of memory inside the DDF address space (ssnmDIST), whereas each in-use DBAT uses approximately 200 K of memory at a minimum, depending on SQL activity.
When the ACTIVE setting used, a DBAT remains active and associated with a specific remote connection from creation to termination, and this method of operation is generally not recommended. For more information, see:
When Db2 operates with inactive connections support enabled, DBATs can be in-use or pooled. A DBAT is in-use when it is processing requests from client connections within a unit of work (UOW). When a DBAT is pooled, it is waiting for the next request from a client to start a new UOW.
With inactive connections support, connections are disassociated from threads. That is, when a DBAT is not processing a client request, it does not need to remain attached the client connection when it is awaiting the next request from the client. The thread is allowed to be pooled and reused for other new or inactive connections. As a result, Db2 can process more connection requests with fewer DBAT and resource usage is improved.
Inactive connections support uses less storage than inactive DBATs (sometimes called "type-1 inactive threads"), which are not supported in Db2 13 or later. (The MAXTYPE1 subsystem parameter is removed in Db2 13 or later, and Db2 13 always operates with the behavior of the 0 setting.) 
The main advantage of reusing DBATs is a greater capacity to support remote connections due to the following reasons:
- CPU savings in Db2, by avoiding repeated creation and destruction of DBATs.
- Real memory savings in z/OS, by reducing the number of DBATs.
- Virtual storage savings in the database services address space (ssnmDBM1), by reducing the number of DBATs.
Because it uses less storage, inactive connection support is preferable. However, not all connections can become inactive.
The following table summarizes the conditions under which you can have an inactive connection. Otherwise, the thread remains active.
| If the event is... | Inactive connections are created? |
|---|---|
| A hop to another location with a pending request 1 | No |
| A package bound with RELEASE(COMMIT) | Yes |
| A package bound with RELEASE(DEALLOCATE) | Yes 2 |
| An outstanding open and held cursor 3, a held LOB locator, or a package bound with KEEPDYNAMIC(YES) | No |
| A declared temporary table that is active (the table was not explicitly dropped through the DROP TABLE statement or the ON COMMIT DROP TABLE clause on the DECLARE GLOBAL TEMPORARY TABLE statement) | No |
- A pending request occurs when a hop connection is created but no SQL statements are run at that location.
- No inactive connections are created for high-performance DBATs. For more information see High-performance DBATs.
- A cursor can be closed with fast-implicit close. For more information, see Fast implicit close.
With inactive connection support, Db2 supports the following three inactive DBAT categories: ordinary pooled DBATs, KEEPDYNAMIC-refresh DBATs, and high-performance DBATs.
Ordinary pooling of DBATs
When a DBAT is not being used to service a connection request, it is pooled and considered disconnected from the connection. It becomes available to process other connection requests. Such DBATs are terminated in any of the following situations:
- After the DBAT is idle in the pool for the duration that is specified by the value of the POOLINAC subsystem parameter.
- After processing 500 units of work.
KEEPDYNAMIC-refresh DBATs
For some distributed applications, especially applications that use packages that are bound with the KEEPDYNAMIC option, Db2 uses extra processing to maintain performance, beyond the basic inactive connection processing. For long running applications that use KEEPDYNAMIC packages, Db2 periodically recycles the DBAT (and the associated connection). The goal is to clean up persistent storage and package resources that are tied to the DBAT due to the KEEPDYNAMIC option. This capability is known as KEEPDYNAMIC-refresh (KDR) processing. KDR processing can be used when both Db2 and the client driver support it.
When a client connection supports KDR processing, and it uses sysplex workload balancing or seamless failover, the Db2 server terminates the thread and connection at a clean transaction boundary in the following situations:
- The DBAT is unused for more than 1 hour.
- The DBAT is not used for a new transaction request for more than 20 minutes.
For more information, see Enabling KEEPDYNAMIC refresh for DBATs.
High-performance DBATs
Although KDR provides significant performance benefits for some applications, it is not suitable for most applications. So, another approach to improve performance was created, called high-performance DBATs. A high-performance DBAT is a database access thread that stays associated with a remote connection at transaction boundaries, rather than being pooled. With high-performance DBATs, the amount of allocation and deallocation processing is reduced because the copy of the package remains allocated until the DBAT terminates.
Normally, any package that is used by a distributed application connection is always acquired as a RELEASE COMMIT package, regardless of the RELEASE bind option specified for the package. However, if the DDF PKGREL option is set to BNDOPT or BNDPOOL, any package that a distributed application connection uses (not just the first) is acquired based on its bound RELEASE setting. Then, if the application uses any RELEASE DEALLOCATE package (not just the current), a DBAT is considered a high-performance DBAT, which is not disconnected from its client connection. For more information, see Enabling high-performance DBATs.
A high-performance DBAT is terminated at a clean transaction boundary in the following situations:
- After processing 500 units of work from the associated client connection.
- After the DBAT is idle in the pool for the duration that is specified by the value of the POOLINAC subsystem parameter. However, if the POOLINAC setting is 0, Db2 still terminates high-performance DBATs, after 120 seconds of inactivity.