DB2 FOR LUW / DB2FORLUW / B10 - DB2

If there was a database outage due to hardware or software 
failure, and at the time of the outage there was an online reorg 
(OLR) running and there was an indoubt transaction modifying the 
same table that is being reorganized, there is a chance that the 
inodubt transaction modified a row that is also being considered 
by OLR.  After crash recovery, the database is open for new 
connections.  Locks should be reacquired data changed by the 
indoubt transaction.  There is a chance that one of the row 
modified by the indoubt transaction is not reacquired.  Instead, 
the unfinished OLR acquired an NS lock on that row.  Queries 
from new connections might be able to see this row, before the 
indoubt transaction is resolved. 
 
One can find the existence of deferred OLR after crash recovery 
by the following message in db2diag.log: 
 
2017-01-29-20.50.46.579355-300 I16657073E525         LEVEL: Info 
PID     : 4278                 TID : 140077770467072 KTID : 4879 
PROC    : db2sysc 
INSTANCE: rzheng               NODE : 000            DB   : 
REORGDB 
APPHDL  : 0-21                 APPID: *LOCAL.DB2.170130015058 
HOSTNAME: hotellnx118 
EDUID   : 83                   EDUNAME: db2reorg (REORGDB) 
FUNCTION: DB2 UDB, data management, 
sqldOLRCleanupAfterCrashRecovery, probe:5701 
DATA #1 : <preformatted> 
Starting ONLINE REORG cleanup (2;3), TID=0000000000000E84. 
 
One can find the existence of indoubt transaction via the 
following : 
 
2017-01-29-20.50.45.359106-300 I16653970E594         LEVEL: Info 
PID     : 4278                 TID : 140081482426112 KTID : 4302 
PROC    : db2sysc 
INSTANCE: rzheng               NODE : 000            DB   : 
REORGDB 
APPHDL  : 0-7                  APPID: *LOCAL.rzheng.170130014954 
AUTHID  : RZHENG               HOSTNAME: hotellnx118 
EDUID   : 18                   EDUNAME: db2agent (REORGDB) 
FUNCTION: DB2 UDB, recovery manager, sqlpresr, probe:3280 
DATA #1 : <preformatted> 
Incomplete trasnsactions (either in-doubt or deferred rolllback) 
exist at the end of crash recovery on log stream 0. 
 
But there is no good way to know if the indoubt transaction 
affected the same table as OLR, and more specifically affected 
the same row that OLR might be processing.

**************************************************************** 
* USERS AFFECTED:                                              * 
* ALL                                                          * 
**************************************************************** 
* PROBLEM DESCRIPTION:                                         * 
* See Error Description                                        * 
**************************************************************** 
* RECOMMENDATION:                                              * 
* Upgrade to DB2 11.1 Mod1 Fix Pack 1 iFix001                  * 
****************************************************************

DB2 Version 11.1 Mod1 Fix Pack1 iFix001 for Linux, UNIX, and Windows
 DB2 Version 11.1 Mod 2 Fix Pack 2 for Linux, UNIX, and Windows
 Db2 Version 11.1 Mod2 Fix Pack2 iFix001 for Linux, UNIX, and Windows
 Db2 Version 11.1 Mod2 Fix Pack2 iFix002 for Linux, UNIX, and Windows
 Db2 Version 11.1 Mod 3 Fix Pack 3 for Linux, UNIX, and Windows
 Db2 Version 11.1 Mod3 Fix Pack3 iFix001 for Linux, UNIX, and Windows
 Db2 Version 11.1 Mod3 Fix Pack3 iFix002 for Linux, UNIX, and Windows
 

First fixed in DB2 11.1 Mod1 Fix Pack 1 iFix001

keiner bekannt / siehe Local-Fix

Datum - Problem gemeldet    :
Datum - Problem geschlossen :
Datum - der letzten Änderung:

30.01.2017
01.05.2017
01.05.2017