PI18028: LONG RUNNING INSERT, TAKING MANY THOUSANDS OF GETPAGES FOR A SINGLE INSERT.

Obtain the fix for this APAR.

APAR status

• Closed as program error.

Error description

• A single INSERT was taking many thousands of GETPAGES.
  
  SMF data showed a single INSERT taking 442830K GETPAGES.
  
  The object was a small classic segmented tablespace.
  

Local fix

• Online REORG of the tablespace.
  Deletion of some rows from the table, if from the pages being
  searched.
  

Problem summary

• ****************************************************************
  * USERS AFFECTED: All DB2 Version 10 / 11 for z/OS using the   *
  *                 TRUNCATE statement operates on classic       *
  *                 segmented or Universal Table space           *
  ****************************************************************
  * PROBLEM DESCRIPTION: High get page count during the          *
  *                      space search after TRUNCATE statement   *
  *                      operates on classic Segmented or        *
  *                      Universal Table space                   *
  ****************************************************************
  * RECOMMENDATION:                                              *
  ****************************************************************
  During the exhaustive search for insert, if the page false
  lead count is exceeded after a few pages are searched within
  the space map page, the algorithm will search more pages before
  moving on to the next step. The segment chain of the last data
  page within the space map page is the anchor point of the
  next set of data pages to be searched. The high get page
  count occurs when the segment chain within the space map
  is not in physical acceding sequence. As a result,
  the same set of segments will be searched repeatedly when the
  process continues to exceed the data false lead count and
  further leads to a high get page count.
  The possible cause for the segment chain being out of physical
  sequence is Truncate or mass delete.
  

Problem conclusion

• DB2 code is modified to limit the search of the same set
  of data pages to no more than 2 times.
  

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:

  UI21563 UI21564

Modules/Macros

• DSNISGSC
  

Fix information

• Fixed component name

  DB2 OS/390 & Z/

• Fixed component ID

  5740XYR00

Applicable component levels

• RA10 PSY UI21563

     UP14/10/16 P F410

• RB10 PSY UI21564

     UP14/10/16 P F410

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.