IBM Support

IT32869: PRIMARY HUNG WHEN HADR_FLAGS= STANDBY_RECV_BLOCKED SSL_PROTOCOL

Subscribe to this APAR

By subscribing, you receive periodic emails alerting you to the status of the APAR, along with a link to the fix after it becomes available. You can track this item individually or track all items by product.

Notify me when this APAR changes.

Notify me when an APAR for this component changes.

 

APAR status

  • Closed as program error.

Error description

  • When using SSL the standby may get into a state
    where it becomes blocked with:
      HADR_FLAGS = STANDBY_RECV_BLOCKED SSL_PROTOCOL
    
    Causing the primary to hang and get stuck in:
    
    0x09000000001180B8 thread_wait + 0x98
    0x0900000079BA2A34 sqloWaitThreshold + 0x994
    0x090000007FA4583C
    sqlpgWaitForLrecBufferLimit__FP14sqlpMasterDbcbCUl + 0x1DC
    0x0900000078E5437C
    sqlpWriteToLog__FP8sqeAgentP11SQLP_TENTRYUlN23P14SQLP_LREC_PARTP
    9SQLP_LSN8PUl + 0x19DC
    0x0900000078E59EB0
    sqlpWriteLR__FP8sqeAgentUlN42P14SQLP_LREC_PARTT2P9SQLP_LSN8PUl +
    0xCF0
    0x090000007B2E6848 IPRA.$sqldWriteDeleteLR__FP13SQLD_DFM_WORKiUl
    + 0x1E8
    0x090000007B2E5500
    sqldLogAndDeleteRecord__FP13SQLD_DFM_WORKiT2Ul + 0x500
    0x090000007B2EFD44 sqldRemoveRow__FP13SQLD_DFM_WORKi + 0x54C4
    0x090000007B2F9268 sqldDeleteRow__FP13SQLD_DFM_WORKiUl + 0xDE8
    0x090000007C5DFFA8 sqldRowDelete__FP8sqeAgentP8SQLD_CCBUlPPv +
    0x8E8
    0x090000007EDE3988 sqlridel__FP8sqlrr_cb + 0x408
    
    This may be due to the following reasons:
    1) using ASYNC, performing large uow (ie. each IO by loggw is
    writing the entire log buffer)
    2)standby receive buffer default is 2*LOGBUFSZ, but standby
    cannot consume the received data yet, until next communication
    with primary
    this is in case primary crashed and the received log data was
    not written to disk on primary(primary overlaps network transfer
    with its own writing to disk, so such possibility exists).
    3)next IO is also entire buffer, and data transferred was
    encrypted(because SSL_PROTOCOL), and we need to decrypt the data
    using the same buffer, which must need a bit extra to facilitate
    the decryption.
    
    We should change our default STANDBY_RECV_BUF_SIZE: ie. standby
    receive buffer should be a bit more than 2*LOGBUFSZ.
    

Local fix

  • Making the DB2_HADR_BUF_SIZE a bit more than 2*LOGBUFSZ.
    

Problem summary

  • ****************************************************************
    * USERS AFFECTED:                                              *
    * THE HADR_FLAGS MAY SHOW STANDBY_RECV_BLOCKED SSL_PROTOCOL    *
    ****************************************************************
    * PROBLEM DESCRIPTION:                                         *
    * See Error Description                                        *
    ****************************************************************
    * RECOMMENDATION:                                              *
    * First fixed in v111m4fp6                                     *
    ****************************************************************
    

Problem conclusion

  • First fixed in v111m4fp6
    

Temporary fix

Comments

APAR Information

  • APAR number

    IT32869

  • 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

    2020-05-14

  • Closed date

    2021-03-31

  • Last modified date

    2021-03-31

  • 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

[{"Line of Business":{"code":"LOB10","label":"Data and AI"},"Business Unit":{"code":"BU053","label":"Cloud & Data Platform"},"Product":{"code":"SSEPGG","label":"Db2 for Linux, UNIX and Windows"},"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"11.1"}]

Document Information

Modified date:
01 April 2021