DB2 FOR LUW / DB2FORLUW / A10 - DB2

On a HADR ROS (Reads enabled standby) system, if the primary 
contains uncommitted in-doubt transactions and a graceful 
takeover is issued on the standby, takeover fails with SQL1773N. 
The standby database will be brought down. The old Primary role 
changes to Standby. 
 
You will notice messages similar to the below one in the 
diaglog, 
 
2013-01-21-13.37.09.582813-480 I302566E667           LEVEL: 
Error 
PID     : 10476                TID : 46913025993024  KTID : 
12410 
PROC    : db2sysc 
INSTANCE: kkchinta             NODE : 000            DB   : SSD 
APPHDL  : 0-12                 APPID: *LOCAL.DB2.130121213216 
HOSTNAME: ramberg 
EDUID   : 42                   EDUNAME: db2agent (SSD) 
FUNCTION: DB2 UDB, data protection services, sqlpgResSpace, 
probe:500 
MESSAGE : ZRC=0x80100469=-2146433943=SQLP_HDRS_READ_ONLY 
          "The operation that attempted to modify the contents 
of the database failed" 
DATA #1 : <preformatted> 
Operation that writes a log record is not supported on HADR 
Standby database. 
 
2013-01-21-13.37.09.585808-480 I303234E552           LEVEL: 
Error 
PID     : 10476                TID : 46913025993024  KTID : 
12410 
PROC    : db2sysc 
INSTANCE: kkchinta             NODE : 000            DB   : SSD 
APPHDL  : 0-12                 APPID: *LOCAL.DB2.130121213216 
HOSTNAME: ramberg 
EDUID   : 42                   EDUNAME: db2agent (SSD) 
FUNCTION: DB2 UDB, recovery manager, sqlprbck, probe:1720 
MESSAGE : ZRC=0x80100469=-2146433943=SQLP_HDRS_READ_ONLY 
          "The operation that attempted to modify the contents 
of the database failed" 
 
2013-01-21-13.37.09.638294-480 I309823E532           LEVEL: 
Error 
PID     : 10476                TID : 46913059547456  KTID : 
15341 
PROC    : db2sysc 
INSTANCE: kkchinta             NODE : 000            DB   : SSD 
HOSTNAME: ramberg 
EDUID   : 65                   EDUNAME: db2hadrs.0.0 (SSD) 
FUNCTION: DB2 UDB, High Availability Disaster Recovery, 
hdrStbyTkHandlePrimaryDone, probe:46510 
MESSAGE : ZRC=0x80100469=-2146433943=SQLP_HDRS_READ_ONLY 
          "The operation that attempted to modify the contents 
of the database failed" 
 
2013-01-21-13.37.09.641381-480 I310356E520           LEVEL: 
Error 
PID     : 10476                TID : 46913059547456  KTID : 
15341 
PROC    : db2sysc 
INSTANCE: kkchinta             NODE : 000            DB   : SSD 
HOSTNAME: ramberg 
EDUID   : 65                   EDUNAME: db2hadrs.0.0 (SSD) 
FUNCTION: DB2 UDB, High Availability Disaster Recovery, 
hdrSDoTakeover, probe:47180 
RETCODE : ZRC=0x80100469=-2146433943=SQLP_HDRS_READ_ONLY 
          "The operation that attempted to modify the contents 
of the database failed" 
 
2013-01-21-13.37.09.643595-480 I310877E417           LEVEL: Info 
PID     : 10476                TID : 46913059547456  KTID : 
15341 
PROC    : db2sysc 
INSTANCE: kkchinta             NODE : 000            DB   : SSD 
HOSTNAME: ramberg 
EDUID   : 65                   EDUNAME: db2hadrs.0.0 (SSD) 
FUNCTION: DB2 UDB, High Availability Disaster Recovery, 
hdrSDoTakeover, probe:47280 
MESSAGE : Standby has failed to takeover.

**************************************************************** 
* USERS AFFECTED:                                              * 
* DB2 LUW HADR users with reads on standby feature enabled.    * 
**************************************************************** 
* PROBLEM DESCRIPTION:                                         * 
* Customer should be using DB2 HADR Reads on Standby feature . * 
* Customer runs into the issue when they issue a takeover on   * 
* standby with an uncommitted in-doubt (XA) transaction on     * 
* Primary. See defect remarks for more information.            * 
*                                                              * 
* Impact:                                                      * 
* ---------                                                    * 
* The takeover on standby will fail with SQL1773N and the      * 
* database will be brought down, the primary database role     * 
* changes to standby. The old standby system can be brought up * 
* as primary (reintegration).                                  * 
**************************************************************** 
* RECOMMENDATION:                                              * 
* Upgrade to DB2 v101 Fixpack 3                                * 
****************************************************************

To prevent running into the issue, resolve the in-doubt 
transactions on Primary before issuing 
the takeover on standby. 
 
If in case, the takeover has already been issued and the standby 
database 
is brought down, then you can bring up the old standby database 
that is down as primary by issuing the command 'start hadr on db 
<dbName> as primary' . After the new primary database is up, 
resolve the indoubt transactions.

DB2 Version 10.1 Fix Pack 3 for Linux, UNIX, and Windows
 DB2 Version 10.1 Fix Pack 4 for Linux, UNIX, and Windows
 DB2 Version 10.1 Fix Pack 3a for Linux, UNIX, and Windows
 DB2 Version 10.1 Fix Pack 6 for Linux, UNIX, and Windows
 

The defect is first fixed in DB2 v101 Fixpack 3

not known / see Local fix

Date  - problem reported    :
Date  - problem closed      :
Date  - last modified       :

21.01.2013
27.09.2013
27.09.2013