The usage and implementation of web applications with DB2 z/OS as the backend for data is growing. New applications have been developed on distributed platforms. They use interfaces to connect to DB2, which only support dynamic SQL statements like JDBC (for Java) or CLI/ODBC (for C, C++, C# programs).
Furthermore, ERP/CRM solutions like SAP or Siebel also work with dynamic SQL statements. Those applications allow their end users to type in several search criteria, which results in SQL statements being built on-the-fly. Mapping such unforeseeable search criteria to prepared static SQL statements can lead to statements with hundreds of cursors. Therefore dynamic SQL statements are a more appropriate solution here.
The access path for dynamic SQL statements is determined at run time, during the prepare process. Determining the access path of a SQL statement can be a very CPU intensive process. Without caching, the prepared statements (or more precisely their skeletons) will be automatically discarded after committing the UOW. Their caching avoids the repetition of the prepare process. Instead of a full prepare of the statement, only a short prepare is required with help of caching. The required pre-conditions are that:
1. the statement is identical to the one in the cache
2. the statement needs to be executed by the same user
3. no changes in table structures or statistics are made
Thus, using the dynamic statement cache is a method to reduce the costs of running dynamic SQL statements.
The memory area for caching dynamic SQL statements is unsurprisingly called “Dynamic Statement Cache” (DSC). More precisely it is called the “Global Statement Cache”, which resides “above the bar” as one DB2’s EDM pool. Global statement caching is enabled by default with the DSNZPARM value CACHEDYN=YES. The size of this cache is controlled via the EDMSTMTC installation parameter which can range from 5 MB to 2 GB.
During the typical online times from 8 am to 6 pm applications with dynamic statements consume a big portion of the CPU capacity available to all DB2 applications. Access path analysis of the cached statements is the first step to optimizing those applications.
Within Toad you can now look into the DSC of the connected subsystem. In Toad version 5.2 is a new tab called “Dynamic Statement Cache” where you get a list of all DSN_STATEMENT_CACHE tables:
If you select one of these tables you will see its contents as shown below. You can filter the grid and also open a selected statement in Toad’s SQL Editor or SQL Tuning lab where you can for example examine the access plan of the statement:
In order to explain statements in the DSC, you need the DSN_STATEMENT_CACHE_TABLE which can be created within Toad as well:
More ...
Category: Toad for IBM DB2