|
Problem IC62192
|
Status: Closed |
A terminated REORG INDEXES ALLOW WRITE ACCESS command may block other transactions from accessing the table. |
| product: |
DB2 FOR LUW / DB2FORLUW / 970 - DB2 |
| Problem description: |
An online index reorg allows other transactions to update the
table and indexes while the reorg is progressing. If the index
reorg encounters an error (such as a lock timeout), it will
fail, but it may not return with an error immediately. A
rollback is triggered which needs to perform some cleanup work
on the indexes before it can complete. That cleanup work may
need to wait for locks held by concurrent transactions that are
accessing the table.
Once all other transactions are complete and release their
locks, the rollback will complete. In the meantime, however, new
transactions that want to access the table are held up because
of the incomplete rollback.
This APAR implements a change to the locking performed by REORG
INDEXES ... ALLOW WRITE ACCESS to allow new transactions to
access the table while the reorg is rolling back, rather than
having to wait for the rollback to complete. |
| Problem Summary: |
****************************************************************
* USERS AFFECTED: *
* Any *
****************************************************************
* PROBLEM DESCRIPTION: *
* Concurrency issues during rollback of a REORG INDEXES with *
* ALLOW WRITE ACCESS. *
****************************************************************
* RECOMMENDATION: *
* Upgrade to the latest fix pack. *
****************************************************************
Index reorg fails because it cannot obtain the lock within the
given lock timeout period. In this example the lock timeout is
0 (no wait), so reorg fails right away. When the timeout is
reached, the reorg must rollback and exit. The reorg does not
return and report the error right away. Instead, it must wait
for the uncommitted transactions from session 1 to commit
(or rollback) before it can complete some cleanup work; only
then can it exit and report the error. In the meantime, other
transaction must wait for reorg to rollback before they can
continue. |
| Local Fix: |
|
| available fix packs: |
DB2 Version 9.7 Fix Pack 1 for Linux, UNIX, and Windows
DB2 Version 9.7 Fix Pack 2 for Linux, UNIX, and Windows
DB2 Version 9.7 Fix Pack 3 for Linux, UNIX, and Windows
DB2 Version 9.7 Fix Pack 3a for Linux, UNIX, and Windows
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 7 for Linux, UNIX, and Windows
DB2 Version 9.7 Fix Pack 9a for Linux, UNIX, and Windows
DB2 Version 9.7 Fix Pack 6 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 10 for Linux, UNIX, and Windows
|
| Solution |
Problem is first fixed in DB2 UDB version 9.7 fix pack 1. |
| Workaround |
not known / see Local fix |
| Timestamps |
Date - problem reported :
Date - problem closed :
Date - last modified :
| 23.07.2009
18.02.2010
06.06.2011 |
| Problem solved at the following versions (IBM BugInfos) |
9.7.FP1
|
| Problem solved according to the fixlist(s) of the following version(s) |
| 9.7.0.1
|
 |
