DB2 - Problembeschreibung
Problem IC89675 | Status: Geschlossen |
Graceful TAKEOVER ON A HADR READS ENABLED STANDBY RETURNS SQL177 3N IF THERE ARE UNCOMMITTED IN-DOUBT TRANSACTIONS ON PRIMARY. | |
Produkt: | |
DB2 FOR LUW / DB2FORLUW / A10 - DB2 | |
Problembeschreibung: | |
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. | |
Problem-Zusammenfassung: | |
**************************************************************** * 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 * **************************************************************** | |
Local-Fix: | |
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. | |
verfügbare FixPacks: | |
DB2 Version 10.1 Fix Pack 3 for Linux, UNIX, and Windows | |
Lösung | |
The defect is first fixed in DB2 v101 Fixpack 3 | |
Workaround | |
keiner bekannt / siehe Local-Fix | |
Weitere Daten | |
Datum - Problem gemeldet : Datum - Problem geschlossen : Datum - der letzten Änderung: | 21.01.2013 27.09.2013 27.09.2013 |
Problem behoben ab folgender Versionen (IBM BugInfos) | |
Problem behoben lt. FixList in der Version | |
10.1.0.3 | |
10.1.0.3 |