PK70060: DGTT MASS DELETE PERFORMANCE ENHANCEMENT (INCLUDES NEW WF SPACE SELECTION ALGORITHM, WHICH APPLIES ONLY TO DB2-MANAGED SPACES)

A fix is available

Subscribe

You can track all active APARs for this component.

APAR status

  • Closed as program error.

Error description

  • DGTT mass delete performance enhancement.   SQLDGTT
    
    DB2MIGV9/K
    

Local fix

Problem summary

  • ****************************************************************
    * USERS AFFECTED: Users of Declared Global Temp Tables (DGTTs) *
    *                 in DB2 V9.                                   *
    ****************************************************************
    * PROBLEM DESCRIPTION: (1) Uncommitted DGTT mass-deletes in    *
    *                          V9 caused performance degradation   *
    *                          for subsequent DGTT insert/delete   *
    *                          operations.                         *
    *                      (2) When the ON COMMIT PRESERVE ROWS    *
    *                          option is in effect for DGTTs,      *
    *                          segments mass-deleted within the    *
    *                          same commit-scope were not reused   *
    *                          after commit.                       *
    *                      (3) DGTTs get SQLCODE -904 more often   *
    *                          in V9, due to lack of needed space, *
    *                          than in V8.                         *
    ****************************************************************
    * RECOMMENDATION:                                              *
    ****************************************************************
    Mass-deleted DGTT segments remained on the segment chain until
    commit or rollback and caused increased overhead for subsequent
    insert/delete operations.
    
    For DGTT's with the ON COMMIT PRESERVE ROWS option, segments
    mass-deleted within the same commit-scope were not reused after
    commit.
    
    DGTTs get SQLCODE -904 more often in V9 than in V8
    for lack of needed space due to the fact that
    DGTTs had their own TEMP data base prior to V9,
    but in V9 they compete for space with work files in the
    WORKFILE data base; and DGTTs (unlike work files)
    cannot span across multiple table spaces.
    

Problem conclusion

  • Code has been optimized
    (1) to provide significant performance
        improvement with DGTT mass-deletes,
    (2) to reuse the space occupied by mass-deleted rows
        at commit for DGTTs with ON COMMIT PRESERVE ROWS
        option, and
    (3) to minimize contention for space between work files and
        DGTTs, by implementing a preference in the selection of
        table spaces that cannot grow beyond the primary space
        allocation (due to SECQTY = 0) for work files use,  and a
        preference in the selection of table spaces that can grow
        beyond the primary space allocation (with SECQTY > 0)
        for DGTT use (please note that this enhancement only takes
        effect on DB2-managed table spaces, not user-managed).
    Some changes will be made in DB2 publications to go with
    this APAR fix. Customers are advised to follow the
    recommendations listed in the publication changes, which
    are documented in the Tracking Comments.
    Please see the Tracking Comments data for details.
    
    While DDL can always be used to create table spaces in
    the work file database, this can also be accomplished by
    using the DSNTWFG installation program. For information
    on how DSNTWFG can be modified to create table spaces in
    the work file database with a preferred value for secondary
    quantity, technote 1386786 is being prepared, currently
    titled "How can I make DSNTWFG create work file table
    spaces with an explicit SECQTY?".
    
    Changes in DB2 publications :
    
    ----------------------------------------------------------------
    1. Performance Monitoring and Tuning Guide :
    
    1A. The following text will be added to the section
        "Creating additional work file table spaces"
        of Performance Monitoring and Tuning Guide :
    
    It is strongly advised that multiple table spaces with zero
    secondary quantity be defined for work files use in the
    WORKFILE data base. DB2 gives preference to table spaces
    with zero secondary quantity when allocating space for work
    files. Multiple work file table spaces help in supporting
    efficient concurrent read and write I/O's to work files.
    
    If applications use Declared Global Temporary Tables (DGTTs),
    it is also advised that some table spaces be defined with
    non-zero secondary quantity in the WORKFILE data base. This will
    minimize contention for space between work files and DGTTs,
    since DB2, when allocating space for DGTTs, gives preference to
    table spaces that can grow beyond the primary space allocation
    (with SECQTY > 0), since DGTTs are limited to one table space
    and cannot span multiple table spaces as the work files can.
    
    If there will be no DGTTs, then it is better that all
    table spaces are defined with zero secondary quantity.
    
    Depending on the number of table spaces and the amount of
    concurrent activity, performance can vary. In general, adding
    more table spaces improves the performance. One may have to
    fine-tune the combination of different types of table spaces
    in the workfile database.
    ----------------------------------------------------------------
    
    ----------------------------------------------------------------
    1B. In section "How sort work files are allocated"
        of Performance Monitoring and Tuning Guide,
     the sentence
       "When your application needs to sort data, the work
        files are allocated on a least recently used basis for a
        particular sort."
     will be changed to
       "When your application needs to sort data, DB2 will
        try to allocate each sort work file on a table space
        that has no secondary allocation (SECQTY = 0) and
        is least recently used. When table spaces with the
        preferred features are not available, then any
        available table space will be used."
    
    ----------------------------------------------------------------
    

Temporary fix

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

Comments

APAR Information

  • APAR number

    PK70060

  • Reported component name

    DB2 OS/390 & Z/

  • Reported component ID

    5740XYR00

  • Reported release

    910

  • Status

    CLOSED PER

  • PE

    NoPE

  • HIPER

    YesHIPER

  • Special Attention

    NoSpecatt

  • Submitted date

    2008-08-04

  • Closed date

    2009-05-22

  • Last modified date

    2011-02-19

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

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

    UK46839

Modules/Macros

  •    DSNDCT   DSNDLKNM DSNDPSFI DSNDSEG  DSNDWACT
    DSNDWFPL DSNIBWAC DSNICMT2 DSNIGWAC DSNISEGD DSNISEGF DSNISGNS
    DSNITNPG DSNIWCUB DSNIWKFL DSNWDFDM
    

Fix information

  • Fixed component name

    DB2 OS/390 & Z/

  • Fixed component ID

    5740XYR00

Applicable component levels

  • R910 PSY UK46839

       UP09/06/09 P F906

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.



Rate this page:

(0 users)Average rating

Add comments

Document information


More support for:

DB2 for z/OS

Software version:

9.1

Reference #:

PK70060

Modified date:

2011-02-19

Translate my page

Machine Translation

Content navigation