maxdbat - 09-29-2009 , 05:25 AM
We changed: maxdbat from 100 to 500, condbat from 500 to 1000 and cthread from 500 to 1000.
Most of the users of this db2 are drda users.
We want to know if these changes can have any influence on in-db2 performance or on virtual
storage areas occupied by db2 ?
Re: maxdbat - 09-29-2009 , 11:57 PM
look at this phrase:
Inactive connection support operates by separating the distributed connections (in DDF) from the threads (DBATs) that do the work (in DBM1). 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 commit time, for another connection to use. 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 only consumes approximately 7.5 K of memory inside the DDF address space, whereas each active DBAT consumes approximately 200 K of memory at a minimum, depending on SQL activity. The DSNZPARM CMTSTAT=INACTIVE enables inactive connection support, and starting with DB2 for z/OS V8, this is the default value for the DSNZPARM.
which is taken from
since you increased maxdbat and condbat, db2 will need more virtual storage to support all the threads and connections. As you can see from the above number, another 400 dbats with 200k per dbat equals 80mb (200k is a minimum), so if this is too much, you might consider lower the number of dbats since db2 can performs connection pooling so unless you have more than 100 concurrent remote requests, you can leave maxdbat at 100.
Regarding cthread, if most of the work is through drda, you won't be needing such a large value