|
Problem IC64072
|
Status: Closed |
"UNABLE TO AUTOMATICALLY REINTEGRATE DATABASE" UNDER PRIMARY/STANDBY REINTEGRATION |
| product: |
DB2 FOR LUW / DB2FORLUW / 970 - DB2 |
| Problem description: |
In clustered environment, after a failover when the old Primary
comes back online, it will automatically reintegrate to become
new Standby. However during the time when the Primary instance
is not available, we may see the following message in the
db2diag.log repeatedly despite a successful auto-reintegration
later on.
2009-05-06-15.17.25.951094-300 I2253902A854 LEVEL: Error
PID : 544798 TID : 1 PROC : db2gcf
INSTANCE: db2inst1 NODE : 000
EDUID : 1
FUNCTION: DB2 Common, Generic Control Facility, gcf_getstate,
probe:260
DATA #1 : String, 83 bytes
Unable to automatically reintegrate database TESTDB. Please
reintegrate manually.
CALLSTCK:
[0] 0x09000000017AA630 oss_log__FP9OSSLogFacUiN32UlN26iPPc +
0x1B0
[1] 0x09000000017AA3FC ossLog + 0x7C
[2] 0x09000000024A4E1C gcf_getstate + 0x1F9C
[3] 0x0900000000305BC0
getState__9GcfCallerFP12GCF_PartInfoUlP11GCF_RetInfo + 0x1A0
[4] 0x0000000100001138 main + 0x7B8
[5] 0x0000000100000290 __start + 0x98
[6] 0x0000000000000000 ?unknown + 0x0
[7] 0x0000000000000000 ?unknown + 0x0
[8] 0x0000000000000000 ?unknown + 0x0
[9] 0x0000000000000000 ?unknown + 0x0
The message in this particular case is due to reintegration
attempts before the instance hosting the old Primary is fully
started. The reintegration attempt is retried at the next hadr
resource monitor interval and then succeeds. So if the later
reintegration is successful (old Primary becomes new Standby and
in peer state), this error message is harmless and can be
ignored.
The APAR fix will only try reintegration when the instance is up
and available, thus eliminating false alarm error messages. |
| Problem Summary: |
****************************************************************
* USERS AFFECTED: *
* Integrated HA solution users *
****************************************************************
* PROBLEM DESCRIPTION: *
* In clustered environment, after a failover when the old *
* Primary *
* comes back online, it will automatically reintegrate to *
* become *
* new Standby. However during the time when the Primary *
* instance *
* is not available, we may see the following message in the *
* *
* db2diag.log repeatedly despite a successful *
* auto-reintegration *
* later on. *
* *
* 2009-05-06-15.17.25.951094-300 I2253902A854 LEVEL: Error *
* PID : 544798 TID : 1 PROC : db2gcf *
* INSTANCE: db2inst1 NODE : 000 *
* EDUID : 1 *
* FUNCTION: DB2 Common, Generic Control Facility, *
* gcf_getstate, *
* probe:260 *
* DATA #1 : String, 83 bytes *
* Unable to automatically reintegrate database TESTDB. Please *
* *
* reintegrate manually. *
* CALLSTCK: *
* [0] 0x09000000017AA630 oss_log__FP9OSSLogFacUiN32UlN26iPPc *
* + *
* 0x1B0 *
* [1] 0x09000000017AA3FC ossLog + 0x7C *
* [2] 0x09000000024A4E1C gcf_getstate + 0x1F9C *
* [3] 0x0900000000305BC0 *
* getState__9GcfCallerFP12GCF_PartInfoUlP11GCF_RetInfo + 0x1A0 *
* *
* [4] 0x0000000100001138 main + 0x7B8 *
* [5] 0x0000000100000290 __start + 0x98 *
* [6] 0x0000000000000000 ?unknown + 0x0 *
* [7] 0x0000000000000000 ?unknown + 0x0 *
* [8] 0x0000000000000000 ?unknown + 0x0 *
* [9] 0x0000000000000000 ?unknown + 0x0 *
* *
* The message in this particular case is due to reintegration *
* *
* attempts before the instance hosting the old Primary is *
* fully *
* started. The reintegration attempt is retried at the next *
* hadr *
* resource monitor interval and then succeeds. So if the later *
* *
* reintegration is successful (old Primary becomes new Standby *
* and in peer state), this error message is harmless and can *
* be *
* ignored. *
* *
* The APAR fix will only try reintegration when the *
* instance *
* is up and available, thus eliminating false alarm error *
* messages. *
****************************************************************
* RECOMMENDATION: *
* Upgrade to DB2 v9.7.0.1 will remove these error messages in *
* scenarios where they can be ignored. *
**************************************************************** |
| Local Fix: |
|
| available fix packs: |
DB2 Version 9.7 Fix Pack 1 for Linux, UNIX, and Windows
DB2 Version 9.7 Fix Pack 2 for Linux, UNIX, and Windows
DB2 Version 9.7 Fix Pack 3 for Linux, UNIX, and Windows
DB2 Version 9.7 Fix Pack 3a for Linux, UNIX, and Windows
DB2 Version 9.7 Fix Pack 4 for Linux, UNIX, and Windows
DB2 Version 9.7 Fix Pack 5 for Linux, UNIX, and Windows
DB2 Version 9.7 Fix Pack 7 for Linux, UNIX, and Windows
DB2 Version 9.7 Fix Pack 9a for Linux, UNIX, and Windows
DB2 Version 9.7 Fix Pack 6 for Linux, UNIX, and Windows
DB2 Version 9.7 Fix Pack 8 for Linux, UNIX, and Windows
DB2 Version 9.7 Fix Pack 9 for Linux, UNIX, and Windows
DB2 Version 9.7 Fix Pack 10 for Linux, UNIX, and Windows
|
| Solution |
The error messages can be safely ignored in this scenario. |
| Workaround |
not known / see Local fix |
| Timestamps |
Date - problem reported :
Date - problem closed :
Date - last modified :
| 22.10.2009
21.12.2009
21.12.2009 |
| Problem solved at the following versions (IBM BugInfos) |
9.7.0.1
|
| Problem solved according to the fixlist(s) of the following version(s) |
| 9.7.0.1
|
 |
