Demystifying the DB2 Dynamic Statement Cache

01/07/16

What Will We Talk About?

Some SQL Tuning Fundamentals

Dynamic SQL in More Detail
Introduction to DB2 Statement Caching
Mining for Gold in the Global Statement Cache

DB2 Tuning - Where Should You Spend Your Time

What Can I tune in DB2

SQL
70%

Subsystem
10%
Object
Analysis
20%

Where are the biggest problems

Purely an estimate and your experience may vary
Many tuning efforts combine multiple areas
Especially true of SQL and Object Analysis

Solving the Problem

SQL Analysis Across the Application Life Cycle

Focus on individual SQL statements

Do they meet best practice coding

standards
Do they use expected/accepted DB2
access paths
Do they deliver desired result set in
acceptable time with acceptable
resource consumption
Developed and tested in controlled
environment
More predictive in nature

Focus on workload dynamics

How does concurrent execution affect
response time/resource consumption
Does this SQL statement/program
collide with other transactions
Same application
Other applications in a shared
subsystem

Real world unpredictability comes into

play
More focus on measuring the workload
and rapidly reacting

SQL Tuning Fundamentals

DB2 Optimizer Determines SQL Performance
SQL Statement
Text
DB2
Configuration

Access Path
To the Data

Hardware
Configuration

TABLE

Schema Definitions
Catalog
Statistics

Tablespace
DB04.TS1

Index
App1.Index1

SQL Tuning Fundamentals

Access Path Selection
Static SQL

For Dynamic SQL

Access Path Selection determined at execution

Access path determined at bind time better

performance

Thats the PREPARE

Exceptions to the Rule
KEEPDYNAMIC bind option

Exceptions to the rule

REOPT (VARS) or (ALWAYS)

Access path determined at run time for those statements

with host variables or parameter markers

Holds prepared statements across commits to avoid cost of

re-preparing statement

PREPARE(DEFER)

Option useful in distributed environments for reducing

message traffic

Authorization for execution at the plan/package level

Qualifiers passed via host variables
SQLJ provides for bound static SQL in Java applications

DB2
Configuration

Global Dynamic Statement Cache

Maintains Skeleton of prepared statements

Build and execute SQL on the fly

User requires authorization to all accessed objects
Parameter markers for passing variables

SQL Statement
Text

Access Path
To the Data

Hardware
Configuration

TABLE

Schema Definitions
Catalog
Statistics

Tablespace Index
App1.Index1
DB04.TS1

 To access DB2 data, an SQL statement requires an access path. Two big factors in the performance of an SQL statement are the amount of time that DB2 uses to determine the access path at run time and whether the access path is
efficient. DB2 determines the access path for a statement at either of these times: When you bind the plan or package that contains the SQL statement

When the SQL statement executes

The time at which DB2 determines the access path depends on these factors: Whether the statement is executed statically or dynamically
Whether the statement contains input host variables
Static SQL statements with no input host variables
For static SQL statements that do not contain input host variables, DB2 determines the access path when you bind the plan or package. This combination yields the best performance because the access path is already determined when
the program executes.

Static SQL statements with input host variables

For static SQL statements that have input host variables, the time at which DB2 determines the access path depends on which bind option you specify: REOPT(NONE), REOPT(ONCE), or REOPT(ALWAYS). REOPT(NONE) is the default. Do
not specify REOPT(AUTO); this option is applicable only to dynamic statements. DB2 ignores REOPT(AUTO) for static SQL statements, because DB2 can cache only dynamic statements.

If you specify REOPT(NONE), DB2 determines the access path at bind time, just as it does when there are no input variables.
DB2 ignores REOPT(ONCE) for static SQL statements because DB2 can cache only dynamic SQL statements
If you specify REOPT(ALWAYS), DB2 determines the access path at bind time and again at run time, using the values in these types of input variables:
Host variables
Parameter markers
Special registers
This means that DB2 must spend extra time determining the access path for statements at run time, but if DB2 determines a significantly better access path using the variable values, you might see an overall performance improvement. In
general, using REOPT(ALWAYS) can make static SQL statements with input variables perform like dynamic SQL statements with constants.

Dynamic SQL statements

For dynamic SQL statements, DB2 determines the access path at run time, when the statement is prepared. This can make the performance worse than that of static SQL statements. However, if you execute the same SQL statement often,
you can use the dynamic statement cache to decrease the number of times that those dynamic statements must be prepared.

Dynamic SQL statements with input host variables: When you bind applications that contain dynamic SQL statements with input host variables, use the REOPT(ALWAYS) option, the REOPT(ONCE) option, or the REOPT(AUTO) option.
Use REOPT(ALWAYS) when you are not using the dynamic statement cache. DB2 determines the access path for statements at each EXECUTE or OPEN of the statement. This ensure the best access path for a statement, but using
REOPT(ALWAYS) can increase the cost of frequently used dynamic SQL statements.

Use REOPT(ONCE) or REOPT(AUTO) when you are using the dynamic statements cache: If you specify REOPT(ONCE), DB2 determines and the access path for statements only at the first EXECUTE or OPEN of the statement. It saves that
access path in the dynamic statement cache and uses it until the statement is invalidated or removed from the cache. This reuse of the access path reduces the cost of frequently used dynamic SQL statements that contain input host
variables; however, it does not account for changes to parameter marker values for dynamic statements.
If you specify REOPT(AUTO), DB2 determines the access path at run time. For each execution of a statement with parameter markers, DB2 generates a new access path if it determines that a new access path will improve performance.
You should code your PREPARE statements to minimize overhead. With REOPT(AUTO), REOPT(ALWAYS), and REOPT(ONCE), DB2 prepares an SQL statement at the same time as it processes OPEN or EXECUTE for the statement. That
is, DB2 processes the statement as if you specify DEFER(PREPARE). However, in the following cases, DB2 prepares the statement twice: If you execute the DESCRIBE statement before the PREPARE statement in your program
If you use the PREPARE statement with the INTO parameter
For the first prepare, DB2 determines the access path without using input variable values. For the second prepare, DB2 uses the input variable values to determine the access path. This extra prepare can decrease performance.
If you specify REOPT(ALWAYS), DB2 prepares the statement twice each time it is run.
If you specify REOPT(ONCE), DB2 prepares the statement twice only when the statement has never been saved in the cache. If the statement has been prepared and saved in the cache, DB2 will use the saved version of the statement to
complete the DESCRIBE statement.
If you specify REOPT(AUTO), DB2 initially prepares the statement without using input variable values. If the statement has been saved in the cache, for the subsequent OPEN or EXECUTE, DB2 determines if a new access path is needed
according to the input variable values.
For a statement that uses a cursor, you can avoid the double prepare by placing the DESCRIBE statement after the OPEN statement in your program.
If you use predictive governing, and a dynamic SQL statement that is bound with either REOPT(ALWAYS) or REOPT(ONCE) exceeds a predictive governing warning threshold, your application does not receive a warning SQLCODE.
However, it will receive an error SQLCODE from the OPEN or EXECUTE statement.

Trends in the Marketplace

Static vs. Dynamic SQL
Dynamic SQL usage is on the increase
Whats driving it?
Dynamic SQL offers flexibility that can simplify developing complex applications
New applications being developed on distributed platforms using connections that
only support dynamic SQL
DB2 CONNECT, etc.

ERP applications implemented with dynamic SQL

SAP, PeopleSoft, Siebel

New applications being developed on distributed platforms

New developers are much more familiar with GUI-based programming environments and
dont even sign on to the mainframe
More Java and C++

SQL Fundamentals - Static SQL

Data access requirements well defined and predictable
Static SQL cursor constructs
Define the Cursor
Host variable defined
In working storage

Open the cursor

Fetch the rows from the result set
Close the cursor

SQL Fundamentals - Dynamic SQL

Data access requirements are ad hoc in nature and
identified on the fly

SELECT Operations

Parameter marker
provides placeholder
for later substitution

Notice the literal

Other operations
Cause the INSERT statement to be prepared and executed
immediately

SQL Fundamentals - Dynamic SQL In Practice

A Statement from a major ERP

application
Built on the fly based on search
criteria selected
A complex statement with
unpredictable input
Default statement syntax includes minimal
number of search criteria
More search criteria the statement
expands to include those search
arguments
If using static SQL could require over 100
cursor definitions in the program

Dynamic SQL Operational Considerations

Sensitive to DB2 statistics

Dynamic SQL always uses current catalog statistics for access path selection
Changes in DB2 statistics can cause unpredictable changes in access paths

Some DB2 customers collect catalog statistics to drive maintenance processes

May cause SQL performance to fluctuate unexpectedly

Security is generally more complex with dynamic SQL

Application users generally require authorization to the objects being accessed

Auditing is also affected because statements are developed on the fly

Governor capability may be required

Performance characteristics can vary widely for dynamic

DB2 Resource Limit Facility may be required

Access path analysis difficult because access path is not available prior to
execution

Dynamic SQL Considerations

PREPARE Yourself

Repeated PREPAREs drive up the cost of dynamic SQL

Prepared statements by default are not persistent across UOWs
Prepare costs vary widely but are significant

Key requirement from anyone developing dynamic SQL applications to

reduce or eliminate the cost of preparing dynamic SQL statements
Driven initially by SAP and other ERP vendors
More in-house dynamic SQL applications drive this requirement

Enter Dynamic Statement Caching

Introduction to Dynamic Statement Caching

Goal is to reduce or eliminate SQL Prepare operations required for dynamic SQL

statements
Implementation
Four kinds of caching

No caching
Local Dynamic Statement Caching
Global Dynamic Statement Caching
Full Caching

Cache prepared SQL statement and statement text for dynamic SQL statements in
DBM1address space
Local Statement Cache
Global Dynamic Statement Cache

Controlled by various parameters

Bind options
DSNZPARMs
Application constructs

Dynamic Statement Caching

No Statement Caching
Prepared statements do not persist across commits
Discarded at commit
Except for statements defined with CURSOR for HOLD

Default mode of operation

Program RRS01

Full
Prepa
re

Used

Thread Storage
Prepared Statement
STMT2(Version 1)

d
arde
Disc

Full
Prepa
re

Used

No prepare returns -514 or -518

Prepared Statement
STMT2(Version 2)

Dynamic Statement Caching

With Local Statement Caching Only
Eliminates need for application to do multiple prepares for same statement
Implicit prepares done by DB2

Enabling Local Statement Caching

KEEPDYNAMIC(YES) Bind Parameter

MAXKEEPD DSNZPARM controls maximum prepared statements
Does not affect statement text which is always kept

Differentiation between prepared statement and statement text

Minimal benefit if used alone

Some reduction in message traffic in a distributed environment is possible

Program RRS01

Full
Prepa
r

Used

a
sc
Di

rd

ed

Implicit
Prepare

Thread Storage
Prepared Statement
STMT2(Version 1)
Statement Text
Retained

Prepared Statement
STMT2(Version 2)

Dynamic Statement Caching

Global Statement Caching Only
Allows reuse of prepared statements across UOWs

Within and across program executions

Prepared statement (SKDS) cached in global dynamic statement cache
Copied into local storage when possible

Short Prepare

Enabling global statement caching

CACHEDYN=YES DSNZPARM value

Storage allocation discussed later

Big benefit for applications with frequent reuse of dynamic SQL

Benefits with no coding changes required

Program RRS01

Full
Prepa
re

RRS01 Local
Thread Storage
Prepared Statement
STMT2(Version 1)
SKDS

SKDS

Global Statement Cache

Program RRS01

SKDS
Shor
t

Prep
a

re

Prepared Statement
STMT2(Version 1)
RRS01 Local
Thread Storage

Dynamic Statement Caching

Where Cached Statements can be Reused
Statement text must be 100% the same
Use parameter markers
Literals wont work (usually)
Additional items must be 100% the same
or compatible
Bind rules
Special registers
Authorizations
Others
You may not get any benefit out of the
dynamic statement cache at all
Most likely to benefit if you using an ERP
or some other application that uses
dynamic SQL extensively

Dynamic Statement Caching

Full Caching A Final Flavor
Combines benefits of local and global statement caching

Ability to completely avoid prepare operations

Prepared statement kept in local thread storage and not invalidated across commits

Prepare Avoidance

Enabling global statement caching

CACHEDYN=YES, MAXKEEPD>0, KEEPDYNAMIC(YES)

Maximum benefit within an application execution
Local thread storage is discarded at thread termination
Program RRS01
Full
Prepa
re

RRS01 Local
Thread Storage
Prepared Statement
STMT2(Version 1)

e
par
Pre
d
ide
Avo

Dynamic Statement Caching

Cost Impacts
Full Prepare
Statement not in cache
Global statement caching not active

Short Prepare
Dynamic statement (SKDS) in the
global cache
Global caching active

Avoided Prepare
Local and global caching active

DB2 Execution Metrics

Dynamic Statement Caching

Impacts on Storage

EDM Pool in DB2 V7

DB2 Database Services

DBM1

DBD

DBD

SKCT

SKCT
PT

CT

CT

SKDS

Caches access path & internal

SKPT
SKDS

SKDS

CT
CT

CT

SKPT

structure definitions
This pool contains
DBDs database descriptors
Skeleton Package and Cursor Tables
(SKPT & SKCT)
Package and Cursor Tables (PT/CT)
Authorization cache block for each
plan (optional)
SKDS - Skeletons of dynamic SQL for
CACHE DYNAMIC SQL (optional)
Optionally stored in a dataspace

Trigger Packages

Dynamic Statement Caching

Impacts on Storage

EDM Pool In DB2 V8

DBM1 - DB2 Database Services
DBDPOOL
DBDs

EDMPOOL now in 3 separate pools

DBDs

EDMDBDC DBDs

GLOBAL STATEMENT CACHE

SKDS

SKDS

SKDS

Above the Bar

EDMSTMTC Dynamic Statements

Above the Bar

2GB Bar EDMPOOL Skeleton Package and

Cursor Tables
EDMPOOL

SKCT
SKPT

PT
CT

Still below the bar and a potential

source of VSC

No dataspace option for Dynamic

Statement Cache

Dynamic Statement Caching

Impacts on Storage

EDM Pool In DB2 V9

DBM1 - DB2 Database Services

DBDPOOL
DBDs

EDMPOOL
DBDs

SKCT

SKPT

CT

PT

Portions of runtime Components

moved above the bar

Plan and package skeletons above
the bar
Bound/Prepared DML Statements

GLOBAL STATEMENT CACHE

SKDS

EDMPOOL

SKDS

CT

SKDS

PT

2GB Bar

Statement Text
SQLDA DESCRIBE output
Portion of native SQL PL package

Portions of static SQL sections

(CT/PT) are moved as well
Further reduces VSC in the DBM1
address space

Dynamic SQL Statement Caching

DB2 Cache Statistics
Statement Pool Full
Failures
Should be 0
Increase Statement Pool
Size if not

Global Cache Hit Ratio

Shoot for 80+%

Local Cache Hit Ratio

Specific for Applications
bound with
KEEPDYNAMIC(YES)

Statement Discarded
Shoot for 0
Increase MAXKEEPD

The Global Dynamic Statement Cache

What Goes In?
Dynamic Statements
If the Global Cache is active (CACHEDYN=YES) and not a REOPT(ALWAYS) application
Reside in the till they are thrown out

DROP or ALTER
Authorization Revoked
LRU
RUNSTATS
DB2 is recycled

Retrieving Data From the Global Cache

As shown previously

Statement caching performance data in DB2 statistics records

Metrics show details about cache hit ratios and other useful data points that help you
evaluate overall performance of your statement caches
For more detail on Global Statement Cache usage the following instrumentation is
provided
IFCID 316 Provides details on statements in the cache
First 60 bytes of SQL text
Includes execution statistics (0 if not being collected)

IFCID 317 can then be used to retrieve the entire SQL statement from the cache once
you have identified the statement of interest
EXPLAIN STMTCACHE
V8 feature that exports Dynamic Statement Cache information to the
DSN_STATEMENT_CACHE_TABLE
Nearly identical to the detail in IFCID 316 & 317
Multiple options including ALL, stmt-id, and stmt-token

Reviewing Global Statement Cache Information

IFCID 316 Results
First 60 Bytes of SQL Text
IFCID

317 gives full text

Bind Options
Statement Statistics (more
later)

Mining the Dynamic Statement Cache

EXPLAIN STMTCACHE ALL
Extracts all statements from the global cache
Inserts one row for each entry in the global DSC

Populates DSN_STATEMNT_CACHE_TABLE only

STMT_ID column matches the Unique ID in the global statement cache
Nearly exact match to the DSC with a few additional columns
STMT_TEXT is a 2M CLOB so be careful with that
COLLID set to DSNDYNAMICSQLCACHE

....

....
DSN_STATEMENT_CACHE_TABLE

Mining the Dynamic Statement Cache

EXPLAIN STMTCACHE STMT_ID
Extracts a single statement from the global DSC

Populates PLAN, DSN_DYNAMIC_STATEMNT, DSN_STATEMENT, and

DSN_FUNCTION tables if they exist
Access path is current access path for statement in the cache
Numeric literal or host variable from program
-248 SQL Return Code back to program is STMT_ID not found

....
PLAN TABLE

....
DSN_STATEMENT_CACHE_TABLE

DSN_STATEMENT_TABLE

Mining the Dynamic Statement Cache

EXPLAIN STMTCACHE STMTTOKEN
Extracts a group of statements from the global DSC

Populates PLAN, DSN_DYNAMIC_STATEMNT, DSN_STATEMENT, and

DSN_FUNCTION tables if they exist
Access path is current access path for statement in the cache
Based on STMT_TOKEN value in the cache
Alphanumeric literal or host variable in program
-248 SQL Return Code returned if no qualifying entries found in cache

....
DSN_STATEMENT_CACHE_TABLE

Mining the Dynamic Statement Cache

More on the STMT_TOKEN in the Cache
Provides a method for grouping similar SQL statements
STMTTOKEN values set using RRSAF or sqleseti functions
Similar to Client special registers implemented in DB2 v8
PL/1 RRSAF Example
Set STMTTOKEN Value
Call to DSNRLI
(RRSAF) with SET_ID
function
Error handling follows

Set Client Special

Registers
Call to DSNRLI
(RRSAF) with
SET_CLIENT_ID
function
Error handling follows

Reviewing Global Statement Cache Information

IFCID 318

Execution statistics for dynamic

SQL statements
Turn on collection with Monitor
trace IFCID 318
Begins collecting statistics and
accumulates them for the length
of time the monitor trace is on
Stop Monitor trace resets all
statistics
2-4% overhead per dynamic SQL
statement stored in the cache
Recommended approach
Run the trace only when actively
monitoring the cache
Use EXPLAIN STMTCACHE to
externalize data for evaluation

Acknowledgements

There are numerous documents that discuss SQL in general and

dynamic SQL in particular, including:

DB2 technical publications

Technical articles by numerous DB2 Subject Matter Experts
IDUG List Server Archives

IBM Redbooks on this topic were especially helpful in researching

this presentation, including:

DB2 for z/OS and OS/390 : Squeezing the Most Out of Dynamic SQL
DB2 UDB for z/OS V8: Through the Looking Glass and What SAP Found
There

Summary
Dynamic SQL is growing in usage
ERP Vendors
Distributed applications

DB2 offers multiple options for reducing the overhead traditionally

associated with dynamic SQL
These options include multiple types of statement caching
Local statement caching
Global statement caching
Full statement caching

DB2 9 will see big changes in the way the SQL statement execution
statistics discussed in this session will be used captured and used