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 IT09204 Status: Closed

IN A TSA AUTOMATED HADR ENVIRONMENT, AN AUTOMATED HADR FAILOVER OCCURS
IMMEDIATELY AFTER A MANUAL TAKEOVER HADR COMMAND IS RUN

product:
DB2 FOR LUW / DB2FORLUW / A50 - DB2
Problem description:
When issuing a manual takeover from the HADR standby, the 
command returns successfully and the standby db becomes the new 
primary. However, immediately afterwards, TSA initiates a second 
takeover request and switches the new primary db back to a 
standby. The reason for this behavior may be that a 
ClusterInitiatedMove resource flag was not cleaned up and still 
exists in /tmp from a previous TSA takeover operation. 
 
If this is the case, then the following db2diag.log message 
should be seen on the standby host at the time that the manual 
HADR takeover command was issued: 
 
2013-09-26-14.17.39.603232-240 E1930E465           LEVEL: Event 
PID     : 2510                 TID  : 47851748976960PROC : 
db2sysc 
INSTANCE: db2inst1             NODE : 000          DB   : HADRDB 
APPHDL  : 0-15                 APPID: 
*LOCAL.db2inst1.130926181739 
AUTHID  : DB2USER1 
EDUID   : 554                  EDUNAME: db2agent (HADRDB) 
FUNCTION: DB2 UDB, base sys utilities, 
sqeDBMgr::StartUsingLocalDatabase, probe:13 
START   : Received TAKEOVER HADR command. 
 
Immediately after the above db2diag.log message, the following 
db2diag.log message should be seen: 
 
2013-09-26-14.17.41.260002-240 E2396E435           LEVEL: 
Warning 
PID     : 2510                 TID  : 47851748976960PROC : 
db2sysc 
INSTANCE: db2inst1             NODE : 000          DB   : HADRDB 
APPHDL  : 0-15                 APPID: 
*LOCAL.db2inst1.130926181739 
AUTHID  : DB2USER1 
EDUID   : 554                  EDUNAME: db2agent (HADRDB) 
FUNCTION: DB2 Common, SQLHA APIs for DB2 HA Infrastructure, 
sqlhaLockHADRResource, probe:181 
 
If this second db2diag.log message is not seen, then this issue 
is being hit. The cause is that the IBM.Test 
ClusterInitiatedMove resource flag was not properly cleaned up 
as part of a prior TSA automated HADR takeover.
Problem Summary:
**************************************************************** 
* USERS AFFECTED:                                              * 
* DB2 10.5                                                     * 
**************************************************************** 
* PROBLEM DESCRIPTION:                                         * 
* See Error Description                                        * 
**************************************************************** 
* RECOMMENDATION:                                              * 
* Upgrade to DB2 10.5 FP7                                      * 
****************************************************************
Local Fix:
In order to confirm whether or not this flag still exists, 
verify the output of the following commands: 
export CT_MANAGEMENT_SCOPE=2 
lsrsrc IBM.Test | grep ClusterInitiatedMove 
 
and: 
 
ls /tmp | grep ClusterInitiatedMove 
 
If the ClusterInitiatedMove flag resource or file exists, it 
will need to be manually removed. In order to remove the flag 
resource, run the following command as root: 
export CT_MANAGEMENT_SCOPE=2 
rmrsrc -s "Name like '%ClusterInitiatedMove%'" IBM.Test
Solution
Workaround
not known / see Local fix
Timestamps
Date  - problem reported    :
Date  - problem closed      :
Date  - last modified       :
29.05.2015
14.01.2016
14.01.2016
Problem solved at the following versions (IBM BugInfos)
Problem solved according to the fixlist(s) of the following version(s)
10.5.0.7 FixList