In the case where the server hosting the primary HADR database
fails, the standby HADR database becomes the new primary, but
the old primary may fail to reintegrate itself as the new
standby database. In this scenario, the user will need to
manually reintegrate the old primary as the new standby. In this
scenario, the following error messages are expected to be seen
in the db2diag.log on the server which encountered the original
failure:
2013-11-06-11.27.25.266888-300 E3596315E520 LEVEL:
Event
PID : 5981 TID : 47691006469888 PROC :
db2sysc 0
INSTANCE: db2inst1 NODE : 000 DB :
HADRDB
APPHDL : 0-970 APPID:
*LOCAL.db2inst1.131106163746
AUTHID : DB2INST1 HOSTNAME: host01
EDUID : 145 EDUNAME: db2agent (HADRDB) 0
FUNCTION: DB2 UDB, base sys utilities,
sqeDBMgr::StartUsingLocalDatabase, probe:13
START : Received START HADR SECONDARY command.
2013-11-06-11.27.28.290831-300 I3691557E942 LEVEL:
Error
PID : 22342 TID : 47836474602240 PROC :
db2gcf
INSTANCE: db2inst1 NODE : 000
HOSTNAME: host01
FUNCTION: DB2 Common, Generic Control Facility, gcf_getstate,
probe:260
DATA #1 : String, 83 bytes
Unable to automatically reintegrate database HADRDB. Please
reintegrate manually.
CALLSTCK: (Static functions may not be resolved correctly, as
they are resolved to the nearest symbol)
[0] 0x00002B81C6E2AC39 pdOSSeLoggingCallback + 0x219
[1] 0x00002B81C61350AB
/mnt/db2/data/db2inst1/sqllib/lib64/libdb2osse.so.1 + 0x2070AB
[2] 0x00002B81C6134ED3 ossLog + 0xA3
[3] 0x00002B81CE4F0872 gcf_getstate + 0x1A52
[4] 0x00002B81C6656457
_ZN9GcfCaller8getStateEP12GCF_PartInfomP11GCF_RetInfo + 0x187
[5] 0x0000000000403D23 main + 0x1023
[6] 0x00002B81CA16EC16 __libc_start_main + 0xE6
[7] 0x0000000000402C69 __gxx_personality_v0 + 0xD9 |
