IT34395: HADR GRACEFUL TAKEOVER FAILED DUE TO XML DICTIONARY CREATION ON PRIMARY THAT CANNOT BE FORCED OFF IN A TIMELY MANNER

Db2 Version 11.1 Mod 4 Fix Pack 6 for Linux, UNIX, and Windows
Db2 Version 11.1 Mod 4 Fix Pack 6 for Linux, UNIX, and Windows

APAR status

• Closed as program error.

Error description

• Graceful TAKEOVER issued on HADR standby database might
  encounter the following error (received after 10 minutes):
  
  
  $ db2 TAKEOVER HADR ON DATABASE mydb
  
  SQL1770N Takeover HADR cannot complete. Reason code = "7".
  
  
  
  The db2diag.log on the standby has the following message:
  
  
  
  2020-07-25-22.10.51.187087-240 I144945345E598        LEVEL:
  Error
  
  PID     : 5564                 TID : 140020828595968 PROC :
  db2sysc 0
  
  INSTANCE: myinstance             NODE : 000            DB   :
  MYDB
  
  HOSTNAME: myhost2
  
  EDUID   : 49                   EDUNAME: db2hadrs.0.0 (MYDB) 0
  
  FUNCTION: DB2 UDB, High Availability Disaster Recovery,
  hdrEduAcceptEvent, probe:20240
  
  DATA #1 : <preformatted>
  
  Standby has not received data from primary for 601 seconds.
  Check the status of the primary. Aborting TAKEOVER.
  
  hdrCurrentTime 1595729451 hdrLastLogRecvTime 1595728850
  hdrGracefulTkTimeout 600
  
  
  
  On the primary database, if "db2pd -stack all" was collected
  during the 10 minutes where the TAKEOVER command was hanging,
  one of the stack has the following:
  
  
  
  0x00007F1992A64C43 sqloReadBlocks + 0x0313
  
                  (/db2/db2inst1/sqllib/lib64/libdb2e.so.1)
  
  0x00007F198D5383A3 sqlbReadPageInternal + 0x05c3
  
                  (/db2/db2inst1/sqllib/lib64/libdb2e.so.1)
  
  0x00007F198D5368D7 sqlbReadPage + 0x0127
  
                  (/db2/db2inst1/sqllib/lib64/libdb2e.so.1)
  
  0x00007F198D4F8D35 _Z19sqlbGetPageFromDiskP11SQLB_FIX_CBi +
  0x0df5
  
                  (/db2/db2inst1/sqllib/lib64/libdb2e.so.1)
  
  0x00007F198D34A6E2 _Z7sqlbfixP11SQLB_FIX_CB + 0x0902
  
                  (/db2/db2inst1/sqllib/lib64/libdb2e.so.1)
  
  0x00007F198CBC44C3
  _Z17sqldcsl_fetchNextP8sqeAgentP8SQLD_TCBP12SQLD_TCB_CSLP16SQLDC
  SL_FETCH_CB + 0x0323
  
                  (/db2/db2inst1/sqllib/lib64/libdb2e.so.1)
  
  0x00007F198CBC287A
  _Z16sqldcsl_fetchRowP8sqeAgentP8SQLD_TCBP12SQLD_TCB_CSLP16SQLDCS
  L_FETCH_CB + 0x009a
  
                  (/db2/db2inst1/sqllib/lib64/libdb2e.so.1)
  
  0x00007F198CB8D4E5
  _Z34sqldcsl_scanObjectAndSampleRecordsP8sqeAgentP8SQLD_TCBP12SQL
  D_TCB_CSLP20SQLD_SAMPLINGPRED_CB + 0x04f5
  
                  (/db2/db2inst1/sqllib/lib64/libdb2e.so.1)
  
  0x00007F198CB8CCE8
  _Z23sqldcsl_buildDictionaryP8sqeAgentP8SQLD_TCBP12SQLD_TCB_CSLjP
  20SQLD_SAMPLINGPRED_CBPP15sqldDictBuilderPP18SQLD_TCB_DICT_INFO
  + 0x0708
  
                  (/db2/db2inst1/sqllib/lib64/libdb2e.so.1)
  
  0x00007F198CB8C28A
  _Z34sqldcsl_buildDictionaryForEstimateP8sqeAgentP8SQLD_TCBP12SQL
  D_TCB_CSLjP20SQLD_SAMPLINGPRED_CBP18SQLD_TAB_DICT_INFO + 0x007a
  
                  (/db2/db2inst1/sqllib/lib64/libdb2e.so.1)
  
  0x00007F198D864EC7
  _Z23sqldGetCompEstimateInfoP8sqeAgentP8SQLD_TCBmP18SQLD_TAB_COMP
  _INFO + 0x07f7
  
                  (/db2/db2inst1/sqllib/lib64/libdb2e.so.1)
  
  0x00007F198D7E70B4
  _Z29sqldGetTableDataForPermOrTempP8sqeAgentP19SQLD_TABLE_DATA_RE
  QP15SQLD_TABLE_DATAtthtm + 0x02f4
  
                  (/db2/db2inst1/sqllib/lib64/libdb2e.so.1)
  
  0x00007F198D7EA27F
  _Z16sqldGetTableDataP8sqeAgentP19SQLD_TABLE_DATA_REQP15SQLD_TABL
  E_DATA + 0x010f
  
                  (/db2/db2inst1/sqllib/lib64/libdb2e.so.1)
  
  0x00007F1993CBB37A
  _Z20sqlrlAdminGetTabInfoP20sqlrl_adm_tabinfo_cb + 0x0c1a
  
                  (/db2/db2inst1/sqllib/lib64/libdb2e.so.1)
  
  0x00007F1990F94F37 _Z29sqlerTrustedRtnCallbackRouterjPPv +
  0x10d7
  
  
  
  The above execution is creating compression dictionary for an
  XML table.  Such execution is not responding to the interrupt
  request issued by the HADR TAKEOVER command.  Thus its long
  execution is blocking the primary database from completing the
  TAKEOVER, resulting in the standby timing out and failing with
  SQL1770N Reason code "7".
  

Local fix

• Upgrade to  v11.1m4fp6
  

Problem summary

• ****************************************************************
  * USERS AFFECTED:                                              *
  * All Users                                                    *
  ****************************************************************
  * PROBLEM DESCRIPTION:                                         *
  * See Error Description                                        *
  ****************************************************************
  * RECOMMENDATION:                                              *
  * Upgrade to  v11.1m4fp6                                       *
  ****************************************************************
  

Problem conclusion

• N/A
  

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:

Fix information

• Fixed component name

  DB2 FOR LUW

• Fixed component ID

  DB2FORLUW

Applicable component levels

• RB10 PSY

     UP