home clear 64x64
en blue 200x116 de orange 200x116 info letter User
suche 36x36
Latest versionsfixlist
11.1.0.7 FixList
10.5.0.9 FixList
10.1.0.6 FixList
9.8.0.5 FixList
9.7.0.11 FixList
9.5.0.10 FixList
9.1.0.12 FixList
Have problems? - contact us.
Register for free anmeldung-x26
Contact form kontakt-x26

DB2 - Problem description

Problem IC71074 Status: Closed

HADR PRIMARY REINTEGRATION SHOULD NOT HAPPEN WHEN TSA IS IN MANUAL MODE

product:
DB2 FOR LUW / DB2FORLUW / 970 - DB2
Problem description:
In a HADR scenario normally when the primary fails, the standby 
will takeover by force. 
Then later on when primary comes back up, it should reintegrate 
to become new Standby. 
 
However, when TSA is in Manual mode, this means automation is 
disabled, and no action should be taken. But this is not the 
case right now. We perform reintegration at the monitor script, 
so even if TSA Manual mode is enabled, reintegration will still 
occur. 
 
This is not the desired effect because it is not honouring the 
TSA Manual mode. 
 
The expectation is that no automation (including reintegration) 
should occur when TSA is in Manual mode.
Problem Summary:
**************************************************************** 
* USERS AFFECTED:                                              * 
* TSA/HADR solution users                                      * 
**************************************************************** 
* PROBLEM DESCRIPTION:                                         * 
* Same as error description                                    * 
**************************************************************** 
* RECOMMENDATION:                                              * 
* Apply DB2 V9.7.0.4                                           * 
****************************************************************
Local Fix:
Change the hadr_monitor script such that it checks whether TSA 
is in Manual mode. 
If in manual mode, then skip the db2gcf call and continue with 
the db2pd / snapshot checks. 
 
e.g. 
+   manual=$(lssamctrl | grep -c "Manual") 
+   if [[ $manual == 0 ]]; then 
+ 
    # Want db2gcf to timeout prior to the monitor method timeout 
... 
    gcfTimeOut=15 
 
    su - ${candidate_P_instance?} -c 
"$INSTHOME/sqllib/bin/db2gcf -t ${gcfTimeOut?} -s -i 
${candidate_P_instance?} -i ${candidate_S_instance?} -h 
${DB2HADRDBNAME?}" 
    grc=$? 
 
    # logger -i -p debug -t $0 "su - ${candidate_P_instance?} -c 
$INSTHOME/sqllib/bin/db2gcf -t ${gcfTimeOut?} -s -i 
${candidate_P_instance?} -i ${candidate_S_instance?} -h 
${DB2HADRDBNAME?} returns $grc" 
+   else 
+      grc=10 
+   fi
available fix packs:
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 6 for Linux, UNIX, and Windows
DB2 Version 9.7 Fix Pack 7 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 9a for Linux, UNIX, and Windows
DB2 Version 9.7 Fix Pack 10 for Linux, UNIX, and Windows

Solution
Apply DB2 V9.7.0.4
Workaround
not known / see Local fix
Timestamps
Date  - problem reported    :
Date  - problem closed      :
Date  - last modified       :
10.09.2010
24.01.2011
24.01.2011
Problem solved at the following versions (IBM BugInfos)
9.7.0.4
Problem solved according to the fixlist(s) of the following version(s)
9.7.0.4 FixList