|
Problem IC64142
|
Status: Closed |
DURING DB2HAICU HADR MOVE OPTION, HADR OLD PRIMARY FAILS TO REINTEGRATE |
| product: |
DB2 FOR LUW / DB2FORLUW / 950 - DB2 |
| Problem description: |
When using the db2haicu move option for HADR instance, old
Standby will takeover by force and become Primary, but old
Primary may fail to reintegrate. db2pd -hadr may show Primary
Disconnected for both. This would happen if clients try to
connect to the old Primary after the move option is used. Note
that this is not a split brain however, as clients will not be
able to successfully connect to old Primary.
In the syslog we may see some hadrV95_monitor.ksh timeouts
followed by db2V95_start.ksh.
Also in the old Primary's db2diag.log we may see entries noting
DBBAD and kill commands from db2gcf.
2009-10-09-12.28.18.266428-300 I2763889A552 LEVEL: Severe
PID : 864352 TID : 4888 PROC : db2sysc
0
INSTANCE: db2inst1 NODE : 000 DB : SAMPLE
APPHDL : 0-20 APPID: GA030317.GD37.091009170850
AUTHID : DB2USER
EDUID : 4888 EDUNAME: db2agent (SAMPLE) 0
FUNCTION: DB2 UDB, relation data serv, sqlrr_rds_common_pre1,
probe:650
MESSAGE : Marking DBBAD since DB not active
DATA #1 : Hexdump, 1 bytes
0x0780000000EC79F2 : 02
...
2009-10-09-12.30.29.357628-300 I3082585A291 LEVEL: Severe
PID : 782408 TID : 1 PROC : db2gcf
INSTANCE: db2inst1 NODE : 000
EDUID : 1
FUNCTION: <0>, <0>, <0>, probe:997
DATA #1 : <preformatted>
Kill Command: su - db2rtin2; db2_kill;ipclean -a |
| Problem Summary: |
****************************************************************
* USERS AFFECTED: *
* Users of db2haicu *
****************************************************************
* PROBLEM DESCRIPTION: *
* When using the db2haicu move option for an HADR instance,the *
* old Standby will takeover by force and become Primary,but *
* the old Primary may fail to reintegrate. The db2pd *
* -hadroutput may show PrimaryDisconnected for both. This *
* wouldhappen if clients try to connect to the old Primary *
* afterthe move option is used. Note that this is not a *
* splitbrain however, as clients will not be able to *
* successfullyconnect to old Primary. In the syslog we may see *
* somehadrV95_monitor.ksh timeouts followed by *
* db2V95_start.ksh. *
****************************************************************
* RECOMMENDATION: *
* Upgrade to DB2 v9.5 FP6 or newer. *
**************************************************************** |
| Local Fix: |
Use the db2 takeover command instead to perform this maintenance
routine. |
| available fix packs: |
DB2 Version 9.5 Fix Pack 6a for Linux, UNIX, and Windows
DB2 Version 9.5 Fix Pack 7 for Linux, UNIX, and Windows
DB2 Version 9.5 Fix Pack 8 for Linux, UNIX, and Windows
DB2 Version 9.5 Fix Pack 9 for Linux, UNIX, and Windows
DB2 Version 9.5 Fix Pack 10 for Linux, UNIX, and Windows
|
| Solution |
Upgrade to DB2 v9.5 FP6 or newer. |
| Workaround |
not known / see Local fix |
| BUG-Tracking |
forerunner : APAR is sysrouted TO one or more of the following: IC64666
follow-up : |
| Timestamps |
Date - problem reported :
Date - problem closed :
Date - last modified :
| 23.10.2009
25.05.2010
25.05.2010 |
| Problem solved at the following versions (IBM BugInfos) |
9.5.FP6
|
| Problem solved according to the fixlist(s) of the following version(s) |
