IBM Support

IT35874: RARE TIMING WINDOW IN GETPARTITIONSTATSSUMMARY CAUSES DB2 SERVER/ DB2SYSC TO ABEND / TRAP

Subscribe

You can track all active APARs for this component.

 

APAR status

  • Closed as program error.

Error description

  • A rare timing window causes DB2 to abend (trap) in
    getPartitionStatsSummary, a function used by the db2stmm tuning
    thread to log instance memory statistics to the Self Tuning
    Memory Manager (STMM) log. This is done even when STMM is not
    configured to actively tune databases.
    
    There is an STMM tuning thread for each database. The timing
    window occurs when a database deactivates at precisely the same
    time as the STMM thread for an active database is performing the
    message logging activity mentioned above. Due to the limited
    exposure, the problem is only likely to occur (but still very
    rare) on systems with one or more databases frequently
    activating and deactivating (eg. a frequent single connection
    submits a simple request and disconnects).
    
    The trap file will show the following functions in the STMM
    tuning thread:
    SqloMemController::getPartitionStatsSummary
    stmmMemoryTunerMain
    
    non-demangled :
    _ZN17SqloMemController24getPartitionStatsSummaryEPKcPNS_21Partit
    ionStatsSummaryEP24SqloPartitionMemoryStats
    stmmMemoryTunerMain
    
    db2diag.log sequence will be similar to the following :
    
    Database DB01 is deactivating :
    2021-02-10-06.04.40.779844-360
    PID     : 35994                TID : 47151228905216  PROC :
    db2sysc 1
    INSTANCE: xxxxx              NODE : 001            DB   : DB01
    Log Manager has been requested by database shutdown to stop for
    log stream 1.
    
    STMM log:
    STMM log shows STMM tuner EDU 572 for a different database DB02
    was just about to write partition stats
    2021-02-10-06.04.43.651154-360
    EDUID   : 572                  EDUNAME: db2stmm (DB02) 1
    FUNCTION: DB2 UDB, Self tuning memory manager,
    stmmMemoryTunerMain, probe:1961
    MESSAGE : Starting New Interval
    
    STMM tuning thread - EDUID 572 - for database DB02 traps:
    2021-02-10-06.04.45.172569-360
    EDUID   : 572                  EDUNAME: db2stmm (DB02) 1
    FUNCTION: DB2 UDB, base sys utilities, sqleagnt_sigsegvh,
    probe:1
    
    ...
    There are 2 workarounds available
    
    1.Keep databases activated.
    The timing window is very small and is not exposed by the
    primary databases on a system (which remain active except for
    maintenance). The problem has rarely been seen, i.e.. when a
    second little-used database was continually stopping and
    starting. It can be explicitly activated (db2 activate database
    <db>).
    
    2.db2set DB2STMM=OFF .
    This will prevent the db2stmm tuning threads from being started
    at database activation time. If STMM tuning is not being used,
    there is no downside to this, other than it requires an instance
    recycle (or, if practical, all databases can be recycled
    individually).
    

Local fix

  • Two workarounds are available:
    
    1. Keep all databases explicitly activated during
    non-maintenance activities
        db2 activate database <database>
    
    2. Disable the activation of STMM tuning threads
        db2set DB2STMM=OFF;db2stop;db2start
    (recycle instance, or ensure that all databases are
    deactivated/reactivated, and no db2stmm tuning threads appear in
    the output of "db2pd -edus")
    

Problem summary

  • ****************************************************************
    * USERS AFFECTED:                                              *
    * all                                                          *
    ****************************************************************
    * PROBLEM DESCRIPTION:                                         *
    * See Error Description                                        *
    ****************************************************************
    * RECOMMENDATION:                                              *
    * Upgrade to 11.1.4.7                                          *
    ****************************************************************
    

Problem conclusion

  • Upgrade to 11.1.4.7
    

Temporary fix

Comments

APAR Information

  • APAR number

    IT35874

  • Reported component name

    DB2 FOR LUW

  • Reported component ID

    DB2FORLUW

  • Reported release

    B10

  • Status

    CLOSED PER

  • PE

    NoPE

  • HIPER

    NoHIPER

  • Special Attention

    NoSpecatt / Xsystem

  • Submitted date

    2021-02-11

  • Closed date

    2022-04-17

  • Last modified date

    2022-04-17

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

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

Fix information

  • Fixed component name

    DB2 FOR LUW

  • Fixed component ID

    DB2FORLUW

Applicable component levels

  • RB10 PSN

       UP

[{"Business Unit":{"code":"BU058","label":"IBM Infrastructure w\/TPS"},"Product":{"code":"SSEPGG","label":"DB2 for Linux- UNIX and Windows"},"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"11.1","Line of Business":{"code":"LOB10","label":"Data and AI"}}]

Document Information

Modified date:
04 May 2022