|
Problem IT01786
|
Status: Closed |
REORG ON A TABLE WITH FOREIGN KEY CONSTRAINT CAN RESULT IN SQL ON PARENT TABLE GETTING LOCK TIMEOUT |
| product: |
DB2 FOR LUW / DB2FORLUW / A10 - DB2 |
| Problem description: |
DB2 will require a lock on a seemingly unrelated table when
performing a select. This can cause unexpected lock timeouts
when a reorg is active.
The following scenario demonstrates the problem.
Consider 3 tables, A, B and C
Table A has a foreign key on table B.
A reorg of table A is started.
A select similar to the following is executed :
select
...
from B left outer join
C on
...
In order to compile this query, DB2 will also evaluate
constraints that may exist on the tables.
As there is a foreign key constraint from A to B, table A will
be locked but the lock mode is incompatible with the current
lock due to the reorg.
The fix for this APAR will relax the locking required so that
table A will no longer need to be locked during query
compilation |
| Problem Summary: |
****************************************************************
* USERS AFFECTED: *
* The following scenario demonstrates the problem. *
* *
* Consider 3 tables, A, B and C *
* Table A has a foreign key on table B. *
* *
* A reorg of table A is started. *
* A select similar to the following is executed : *
* *
* select *
* ... *
* from B left outer join *
* C on *
* ... *
* *
* In order to compile this query, DB2 will also evaluate *
* constraints that may exist on the tables. *
* As there is a foreign key constraint from A to B, table A *
* will *
* be locked but the lock mode is incompatible with the current *
* lock due to the reorg. *
****************************************************************
* PROBLEM DESCRIPTION: *
* See Error Description *
****************************************************************
* RECOMMENDATION: *
* Upgrade to DB2 10.1 FP5 *
**************************************************************** |
| Local Fix: |
|
| Solution |
Version containing the fix:DB2 10.1 FP5
DB2 will require a lock on a seemingly unrelated table when
performing a select. This can cause unexpected lock timeouts
when a reorg is active.
The fix for this APAR will relax the locking required so that
table A will no longer need to be locked during query
compilation |
| Workaround |
not known / see Local fix |
| Timestamps |
Date - problem reported :
Date - problem closed :
Date - last modified :
| 13.05.2014
15.07.2015
15.07.2015 |
| Problem solved at the following versions (IBM BugInfos) |
|
| Problem solved according to the fixlist(s) of the following version(s) |
| 10.1.0.5
|
 |
