DB2 for z/os Best Practices DDF Connectivity John J. Campbell Distinguished Engineer DB2 for z/os Development db2zinfo@us.ibm.com 2011 IBM Corporation Transcript of webcast Slide 1 (00:00) Hello, this is John Campbell here a Distinguished Engineer in DB2 for z/os development. Welcome to today s web lecture about DDF connectivity. This is one of the web lectures in a whole series about DB2 for z/os best practices. Let s turn to slide 2. Slide 2 (00:17) On slide 2 here I have a disclaimer about particular trademarks that are used in this presentation. Now let s go to slide 3. Slide 3 (00:28) One of the most important things to understand here is the distinction between active threads and inactive connections. And those words, threads versus connections, is very impor-
tant, okay? So we are talking about active threads which are DBATs versus the inactive connections. There are two modes of running distributed threads controlled by a ZPARM called CMTSTAT. First of all you can set this to ACTIVE. In which case, every connection is a database access thread, a DBAT, a thread inside DB2. And it s held until the basic connection is broken. In other words, it is held until it is disconnected. Even when waiting for new client transactions. So you can clearly see that if you set CMTSTAT equals AC- TIVE, you can consume and hold on to a large number of database access threads. And this is very important prior to version 10 because the thread storage just like the regular allied threads. Most of this thread storage is held below the 2 gigabyte bar in the DBM1 address space. The other value for CMTSTAT is called INACTIVE, this is the default. And this is where we have this concept of thread pooling or DBAT pooling inside DB2. We used to have CMTSTAT equal to INACTIVE to strongly recommend. The DBAT is pooled and this applies to DRDA or it goes inactive if you are using private protocol when the connection issues a commit or a rollback. And a certain number of connections are met. So I ll repeat that, when you have CMTSTAT equal to INACTIVE, the DBAT is pooled if it is DRDA or it goes into inactive if it is private protocol when the connection issues a commit or rollback. What does that mean? It means we have pool of database access threads, DBATs in the case of DRDA of a certain size. And basically, when the application gets to a commit or rollback point, what we actually do, is dissociate the connection that was running the application from the database access thread and what we do is we part the connection which has a very low storage footprint and what we then do is put the database access thread, DBAT back into the pool so that it can be reused by other connections.
The second half of this chart 3 is very important. Because in order for the DBAT to be pooled and for the connection to go inactive for DRDA, certain connections have to be met. In other words, there is no WITH HOLD cursors, no Declare Global Temporary Tables on the connection, no LOB locators, and no package defined and running with KEEPDY- NAMIC YES. The opposite is true, like you have WITH HOLD cursors, DGTTs, LOB locators, and user KEEPDY- NAMIC, and these will stop the DBAT being pooled and the connection going inactive. So it is very important in a performance and highly available environment to make sure your applications do not have these conditions. So it is very important to close WITH HOLD cursors before commit and rollback. To basically close and drop DGTTs. And basically not to run with packages that are running with KEEPDY- NAMIC YES. Now let s turn to slide 4. Slide 4 (03:46) Now I m going to talk about, in more detail here, about inactive connections. And this is specific, really this discussion here is very specific to DRDA. Now remember that in version 10, private protocol finally goes away. So there is actually zero tolerance in DB2 version 10 for any private protocol. So most of this discussion in this presentation and web lecture is going to be focused on DRDA. So basically, for DRDA connections we have this thing called inactive connection support. We used to call this previously, type 2 inactive thread support. And this term, type 2 inactive thread support was very confusing. It s got absolutely nothing to do with threads at all. It s about connections. It s about pooled use of database access threads. And it is about connections going inactive. So a better description here, used in this slide here, is inactive connections. So what happens in a
well behaved application is that upon commit, the DBAT is marked in disconnected state, which means it s pooled. And it is put back in the pool of DBATs to be used by the connections and the connection becomes inactive. So basically the DBAT is back in the pool. It can be used by any of the other inactive connections, or any new connection coming through. Any new unit of work request that comes in on an existing connection, inactive connection, or new connection, will be dispatched on one of the pooled DBATs, if one exists. It is possible that MAXDBAT which is a throttle on the total number of database access threads may have already been reached. In which case there is no pooled DBAT available in the pool for use. If all the DBATs are currently in use, DB2 will create a new DBAT provided MAXDBAT has not already been reached. If MAXDBAT has been reached, then the request will be queued. So basically, we have this concept of pooled DBATs and after 200 state switches or 200 reuses of a DBAT then the DBAT is purged. In other words it is rejuvenated. Another point is that if you have a pulled DBAT that has been put back in the pool, and it hasn t been used for a certain period of time then we ll purge the DBAT as well. So we have a DB2 system s parameter called POOLI- NAC with a default of 120 seconds. So if have a pooled DBAT that hasn t been reused within a default of 2 minutes then we purge the DBAT. So use of inactive connection support is highly recommended and is the best for resource utilization. And in most situations a small number of database access threads, can typically be used to service a large number of connections. The number of database access threads is defined by a system parameter called MAXDBAT and the maximum number of connections is called CONDBAT. Again you can have
many more connections than you have database access threads. There is a picture in the bottom right hand corner here, which hopefully can be used to reinforce the information I have already given to you. So here you have in this simple picture here. You have the DDF address space and you have the DBM1 ID. And in this example here, we have basically 50 connections, but only 5 of them are active. And those are colored in blue. In the right hand side here, we have the DBM1 address space where we have a set of DBATs defined by MAXDBAT. In this case we actually have a pool with 9 DBATs which are pooled. Of which 5 of them are assigned to a connection. So as you can see here, we have 5 out of 50 connections which are active. And they are using 5 of the DBATs in the pool. That leaves 4 DBATs available in the pool to be used by an inactive connection that wakes up, or by a new connection coming through. Now let s turn on to slide 5. Slide 5 (07:44) I m now going to talk about inactive DBAT. I m not going to spend a lot of time on this. This is unique to private protocol. And as I said, this will be going away in version 10, and you must limit all use of private protocol and convert it over to DRDA before you migrate to version 10. So the concept of inactivity is very different in private protocol. Basically, the connections don t go inactive. Basically you have the concept of an inactive DBAT support. And we used to call this previously, the type 1 inactive thread. What happens here is that basically the DBAT memory footprint is reduced and the DBAT goes inactive. So we still hold on to the database access thread but we basically shrink down the memory footprint. So when a new unit of work request comes through on
that connection. We would use the DBAT to return to an active state and basically the memory footprint is expanded. So basically we are shrinking and expanding the memory footprint for the database access thread depending on whether we have work to do. So basically, when you ve got private protocol in this inactive DBAT support it is tied to the user s connection. There is no thread pooling like I described previously that we have for DRDA. So potentially with private protocol, you can consume a very large number of threads in order to support a large number of connections. The DB2 ZPARM, MAXTYPE1, controls how many DBATs using private protocol can go inactive. If the value of that ZPARM is set to zero, any DBAT that uses private protocol will stay active. In other words, if you set it to a non-zero value, this defines the maximum number of DBATs using private protocol that can be inactive concurrently. Now let s turn on to slide 6. Slide 6 (09:41) Over the next three slides here, I would like to talk through some of the instrumentation that is available for DDF. There are an awful a lot of counters in this particular space. And sometimes it s not clear based on the short name of the instrumentation counter. And even the longer name, as to what it really means. But probably more importantly, what are the critical information. So on slide 6 here, we ve got the output here of the DIS- PLAY DDF DETAIL command. And I ve used various color codes here. So if you look at the green ones to start with, this gives you information. So the DT parameter tells you basically whether the ZPARM is configured to have inactive or active. So A means active, inactive means I. CONDBAT
reflects the maximum inbound connections that are possible. And this should reflect the DB2 systems parameter, COND- BAT. MDBAT, reflects the maximum number of database access threads that are possible and this should reflect the DB2 systems parameter called MAXDBAT. Now the blue ones, counters here, are informational. Later on I m going to move to the red counters which are the most important. So what does ADBAT mean? It actually means the current number of DBATs. Both those assigned (assigned to connections to do work), plus those disconnected DBATs that are back in the pool that can be used by an inactive connection that wakes on or by a new connection coming through. We then have the next blue one DSCDBAT is the current number of disconnected DBATs in the pool. It s the number of pool DBATs that are available for reuse. And INACONN is the current number of inactive connections. Now, the two red counters are the ones to focus on. QUEDBAT is a cumulative counter incremented every time MAXDBAT is reached. Note carefully, it is only reset at DDF restart. So this will accumulate over time, going upwards until DDF is recycled. And obviously every time you reach MAXDBAT, then a new connection coming through or an existing inactive connection that wakes up, will have to wait until a pool connection becomes available. Sorry a pool DBAT becomes available. Then we have CONQUED, this is the current number of queued requests that are waiting to be serviced by the DBAT. This reflects the same thing here, in that we ve reached MAXDBAT and we have connection requests that are waiting to be serviced. Now let s turn on to slide 7. Slide 7 (12:25)
Now in slide 7 here, we have a section on the DB2 statistics report. It s called the Global DDF Activity section. And again, basically, I ve described these fields and highlighted them in blue, green, or red. And clearly some of these will map onto information that I have already given to you. What I want to do here is focus on the red counters. First of all, you ve got CUR QUEUED TYPE 2 INACT THR. This is the current number of connections queued for the DBAT. In other words, again this indicates queuing for DBAT as MAXDBAT is reached and we have either new connections coming through, waiting, or we have previous inactive connections that are now active and are waiting for a DBAT. So we have queuing occurring. Then we have DBAT QUEUED-MAXIMUM ACTIVE, this is the number of times that MAXDBAT was reached. And lastly we have a situation where CONV.DEALLOC-MAX.CONNECTED, this is the number of times CONDBAT was reached. And this is important because when CONDBAT is reached any new connections coming through will be rejected. So monitoring these red counters is very important. And now let s turn to the final slide. Slide 8. Slide 8 (13:48) Now what I want to talk here about is block fetching. This is a very important concept. Now what I m showing here in the bottom right hand corner here is a section, again, from the DB2 statistics report showing DRDA remote location section. So why is block fetching important? This is because if you have SQL requests that are not eligible for block fetch. Then each request at a very high level results in a message send and receive between the client or requester and the DB2 server. So the concept of block fetch and it particularly applies here to read cursors where you are pulling lots of rows.
Is that with block fetch enabled, DB2 will group rows that are retrieved by a query into a large block, potentially a large block of rows, that will fit into a message buffer. The advantage here is that it has the potential to significantly decrease the number of messages sent across the network between the client or requestor and the server. Most importantly, block fetch is used only with cursors that do not update or delete data. So if you have a cursor, a cursor that is defined cursor control select, that is defined for update or for delete, then that will disable block fetch. Now there are two ways of enabling block fetch for cursors. One is you can define the cursor, basically as being read only. You can say for fetch or for read only. Also, DB2 is clever enough to figure out that some cursors are implicitly read only because an order by a group by, distinct, or union for example. But some cursors are ambiguous. In other words you can t tell by looking at the SQL statement that it is read only. And one thing you can do as an application developer or systems administrator is to encourage block fetch for those ambiguous cursors. And a way to do that is to bind your static SQL packages with current data no. And that will encourage block fetch. So when you are looking at this section of the DB2 statistics report you need to distinguish between rows and blocks, the values. And basically if you end up with a high number of rows relative to the number of blocks, this is an indicator of block fetch efficiency. So here for example, this example, you can see that we have received almost 9000 rows, 8733 rows, but it is blocked into 23 blocks. This is an indicator of very high block efficiency. Anyway, this completes this particular web lecture on DDF connectivity and how to interpret the information you receive
in the display DDF command and also in the DB2 statistics trace. (16:40)