PH35088: HIGH CPU DUE TO LONG PREPARES AND LOW HIT RATIO IN DYNAMIC STATEMENT CACHE WHEN DYNAMIC SQL PLAN STABILITY IS ENABLED

Obtain the fix for this APAR.

APAR status

• Closed as program error.

Error description

• Dynamic SQL statements may experience performance degradation
  (long prepares) when dynamic SQL plan stability is enabled and
  PTF UI71423 is applied. Also, the dynamically stabilized SQL
  statements may not be found in the Dynamic Statement Cache so
  the hit ratio may be lower than expected.
  
  
  Additional keywords: SQLDYNSTMTCACHE SQLDPS
  

Local fix

• 1. Remove PTF UI71423
  OR
  2. Use the FREE STABILIZED DYNAMIC QUERY command to remove the
  stabilized statements and turn off the system parameter
  CACHEDYN_STABILIZATION so that no accidental captures
  are done.
  

Problem summary

• ****************************************************************
  * USERS AFFECTED:                                              *
  * All Db2 users of the Dynamic Plan                            *
  * Stability (DPS) SQL who have applied                         *
  * PH27078/UI71423.                                             *
  ****************************************************************
  * PROBLEM DESCRIPTION:                                         *
  * Running an DPS SQL statement could                           *
  * experience high CPU usage due to                             *
  * extra                                                        *
  * full prepare for an DPS SQL statement                        *
  * after PH27078/UI71423 is applied.                            *
  ****************************************************************
  * RECOMMENDATION:                                              *
  * Apply corrective PTF when available                          *
  ****************************************************************
  One field of an internal control data structures is
  not initialized for DPS SQL when the DPS SQL is
  cached in EDM statement cache pool.
  After applying PH27078/UI71423, executing a cached
  DPS SQL statement takes an extra full prepare due to missing
  information in the internal control block.
  PH27078 fixed a timing window problem where running
  an SQL statement could incorrectly reference another SQL's
  internal data structure which resulted in
  unexpected behavior.
  

Problem conclusion

• Db2 has been changed to initialize the data
  strcture correctly when an DPS SQL statement is cached in
  the pool.
  Before applying this apar change, customer can
  get around this issue by clean the cache of
  the DPS SQL entries and disable DPS captures
  as below,
  FREE STABILIZED DYNAMIC QUERY STBLGRP (*)
  -STOP  DYNQUERY CNO(*)
  Additional keywords: PERFM,SQLPERFORMANCE
  DB2AIV1R4/K
  

Temporary fix

• *********
  * HIPER *
  *********
  

Comments

APAR Information

• APAR is sysrouted FROM one or more of the following:

• APAR is sysrouted TO one or more of the following:

  UI74809

Modules/Macros

• DSNGEDYI
  

Fix information

• Fixed component name

  DB2 OS/390 & Z/

• Fixed component ID

  5740XYR00

Applicable component levels

• RC10 PSY UI74809

     UP21/04/15 P F104 ­

Fix is available

• Select the PTF appropriate for your component level. You will be required to sign in. Distribution on physical media is not available in all countries.