PI44165: LARGE NUMBER OF ACCESSES TO CSQ.OBJ_B_QUEUE USING PLAN CSQ5R710 15/09/01 PTF PECHANGE

Obtain the fix for this APAR.

APAR status

• Closed as program error.

Error description

• The initial symptom was 800,000 DB2 SMF records being cut per
  hour as a result of MQ activity.  DB2 traces tracked this to
  plan CSQ5R710 and identified very many sequences of
  open/fetch/close on CSRQUEUE cursor in CSQ5AROB.
  
  Periodically, the queue-manager will check in DB2 for any new
  queues which have been created. It should only check for new
  queues since the last time it checked. However, if a queue
  which is not a temporary dynamic queue is deleted, the 'last
  time checked' time-stamp will be reset to the time the
  queue-manager was started (this change was made by PM79700).
  This means that if there are shared dynamic queues being
  deleted frequently (e.g. due to MQCO_DELETE_PURGE being used)
  this can cause the issue seen here with a large number of
  accesses to CSQ.OBJ_B_QUEUE using plan CSQ5R710).
  .
  Additional keywords:
  SQL performance
  

Local fix

• No local fix
  

Problem summary

• ****************************************************************
  * USERS AFFECTED: All users of WebSphere MQ for z/OS Version 7 *
  *                 Release 0 Modification 1 and Release 1       *
  *                 Modification 0.                              *
  ****************************************************************
  * PROBLEM DESCRIPTION: Increased CPU usage, and increased      *
  *                      usage in DB2 when permanent dynamic     *
  *                      (shared and private) queues are deleted *
  *                      frequently after application of PTF's   *
  *                      for APAR PM79700.                       *
  ****************************************************************
  * RECOMMENDATION:                                              *
  ****************************************************************
  During the delete processing of a queue, after changes
  introduced by PM79700, the time the last refresh of shared
  queues from DB2 is reset to the start time of the queue manager
  if the queue being deleted is not a dynamic queue. However the
  logic currently is incorrect for permanent dynamic (shared and
  private) queues, resulting in csRefreshSTCK being reset for this
  type. This results in refresh processing going through all new
  queues defined since the start of the queue manager, when this
  type of dynamic queue is deleted. In a system with shared
  dynamic queues being frequently deleted, this will result in
  higher usage of DB2. This can be seen in DB2 SMF accounting
  records showing higher usage by the MQ plan CSQ5R710 (MQ V710)
  or CSQ5R7P1 (MQ V701).
  

Problem conclusion

• The deletion processing for a queue object has been altered to
  no longer reset the refresh time for shared and permanent
  dynamic queues. This will reduce the number of new queues being
  checked, after a refresh when shared dynamic queues are deleted.
  010Y
  100Y
  CSQEDB2R
  CSQEKATM
  CSQE197N
  CSQIDDEL
  CSQIDEL5
  CSQIERS3
  CSQILEPL
  CSQILOC2
  CSQMOAQ1
  

Temporary fix

Comments

APAR Information

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

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

  PI47893 UI31283 UI31284

Modules/Macros

• CSQEDB2R CSQEKATM CSQE197N CSQIDDEL CSQIDEL5 CSQIERS3 CSQILEPL
  CSQILOC2 CSQMOAQ1
  

Fix information

• Fixed component name

  WMQ Z/OS V7

• Fixed component ID

  5655R3600

Applicable component levels

• R010 PSY UI31283

     UP15/11/11 P F511 {

• R100 PSY UI31284

     UP15/11/11 P F511 {

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.