2. Introduction
These days, more and more Dynamic SQL is running on DB2 for z/OS and the proportion is increasing.
Those SQL Statements are coming from a variety of applications and platforms. One thing all Dynamic SQL
statements have in common is that before going into the DB2 Engine to be executed one of their stops is the
Dynamic Statement Cache (DSC).
The DSC is a storage pool in which DB2 saves prepared SQL statements access paths be shared among different
threads, plans, and packages. By sharing those statements, applications can avoid unnecessary preparation
processes and thus improve performance. After an SQL statement has been prepared the Statement Text and
its access path are automatically saved in the cache. Subsequent prepare requests for that same SQL statement
can avoid the costly preparation process by using the access path that’s already stored in the cache.
There are several ways to identify Dynamic SQL statements in APPTUNE for DB2. If it’s a long running
application, the “View current DB2 status by subsystem” menu shows running active threads. You can easily
check for the DISTSERV Plan from “SUMMARY OF ACTIVE THREADS” screen and then drill down to find more
details.
If the thread is already completed, the “Analyze current and historical SQL workloads” menu shows near-Term
History of threads.
Another alternative is the “Analyze dynamic statement cache statistics” menu which is the main focus area
of this section. It provides a general picture of dynamic statement cache performance at low cost with some
additional functions.
DETAILS...
In order for the DSC metrics to be available, DB2 IFCID 318 must be active in a trace. IFCID 318 can be easily
activated inside Apptune by using the DSC feature. You don’t need to keep it “active” all the time. In a heavy
loaded system, activating it only for a few minutes provides plenty of valuable information.
Identify a Tablespace Scan caused by a RID List failure, rather than its original access path.
A tablespace scan is easily identified in DB2 Plan Table by a value of “R” in the Access Type column if this is the
original access path. However, a more reasonable access path can also be converted into a tablespace scan at
runtime, when it’s much harder to find. Let’s check the following scenario.
IFCID 318 is activated for 14 seconds and data is collected for 13,672 SQL Calls as follows
If you look at the detail of the collection period using the “T” drill down option, the following section gives you a
good summary of the running SQL statements. If the number of “Tablespace Scans” and “Sorts Performed” are
greater than zero, it means there are SQL Statements that are not using indexes efficiently or perhaps there is
no valid Index at all.
1
3. The next step is to check the SQL statements in the DSC, sorted by GETPAGE. It’s always very easy in Apptune
to create an ordered list. Move your cursor on the Getpage column and press PF4 for ascending order or PF5
for descending. It’s likely that the statement with the highest average number of getpages is the one doing the
Tablespace Scan and/or Sort operation. As a cautionary note, the Tablespace Scan field not only shows the
access path itself, it also indicates when an SQL access path was changed into a Tablespace Scan after RID Pool
failures. Be sure to check for this possibility before taking any action steps.
See the example below. There is one SQL Statement whose Getpage count (1720) is significantly larger than the
rest.
Let’s check to see if there are any RIDPool failures.
When the SQL statement (above) with the highest Getpages count is EXPLAINed (using the Explain option (X))
there is no Tablespace Scan shown. However you will see Multi-Index access and List Prefecth, which means the
RIDPool will be used during execution
2
4. SELECT *
FROM FEE_CD A, FEE_STD B, FEE_MSTR_RATE D
WHERE A.LDBID = ? AND A.LDBID = B.LDBID
AND A.APRVL_VALUE = ‘appr’ AND A.FLST_VALUE = ‘actv’
AND A.FECD_EFCTV_DATE <= ? AND A.FECD_HOST_TS =
(SELECT MAX(C.FECD_HOST_TS)
FROM FEE_CD C WHERE C.LDBID = ?
AND C.FECD_EFCTV_DATE <= ? AND C.CDN_IDFR = A.CDN_IDFR
)
AND B.CDN_IDFR = A.CDN_IDFR_FECD_IS_D
AND B.CRUD_VALUE <> ‘D’ AND B.FES_EFCTV_DATE <= ?
AND B.CDN_IDFR = ? AND B.FES_HOST_TS =
(SELECT MAX(FES_HOST_TS)
FROM FEE_STD
WHERE CDN_IDFR = B.CDN_IDFR
AND FES_EFCTV_DATE <= ?
)
AND D.LDBID = A.LDBID
AND D.FEMR_IDFR = A.FEMR_IDFR AND D.FEMR_EFCTV_DATE <= ?
AND D.APRVL_VALUE = ‘appr’ AND D.FEMR_HOST_TS =
(SELECT MAX(FEMR_HOST_TS)
FROM FEE_MSTR_RATE
WHERE LDBID = ? AND FEMR_IDFR = D.FEMR_IDFR
AND FEMR_EFCTV_DATE <= ?
)
AND NOT EXISTS
(SELECT 1
FROM FEE_PRFL_CD T4
WHERE T4.LDBID = ?
AND T4.CDN_IDFR_FPC = A.CDN_IDFR
3
5. AND T4.RIFS_IDFR = ? AND T4.FPC_HOST_TS =
(SELECT MAX(FPC_HOST_TS)
FROM FEE_PRFL_CD
WHERE LDBID = ? AND CDN_IDFR = T4.CDN_IDFR
)
)
ORDER BY FECD_NAME
FOR READ ONLY
When we look at the details of the SQL Statement, we see that there are 210 RID List failures
4
6. As well as 210 Tablespace scan as follows.
This proves that the cause of those tablespace scans are are RIDPool failures rather than the original path,
and it would be very difficult to determine this without execution statistics at the Statement level. The next
steps should be to check the related RID Pool DSNPARM settings to determine whether changing these may
help, as well as evaluating the Statement itself to determine whether the dependence on the RID pool can be
reduced.
About the Author
IBM Champion Cuneyt Goksu is an independent DB2 specialist and IBM Gold Consultant
since 2009. His main activity is linked to DB2 for z/OS and LUW Installation, Migration,
Administration and Performance Tuning. He has presented papers at several
conferences, local events and writing articles for IT magazines. Cuneyt is currently a
member IDUG Board of Directors, he is the leader of Turkish DB2 Users Group and IBM
Authorized DB2 Training Partner. Cuneyt can be reached at cuneytgoksu@usa.net
5