Latest versionsfixlist
11.1.0.7 FixList
10.5.0.9 FixList
10.1.0.6 FixList
9.8.0.5 FixList
9.7.0.11 FixList
9.5.0.10 FixList
9.1.0.12 FixList
Have problems? - contact us.
Register for free anmeldung-x26
Contact form kontakt-x26

DB2 - Problem description

Problem IC90024 Status: Closed

OPTIMIZER MIGHT FAVOUR HSJOIN OVER AN ORDERED NLJOIN

product:
DB2 FOR LUW / DB2FORLUW / 970 - DB2
Problem description:
The optimizer might favour a hash join (HSJOIN) over a nested 
loop join (NLJOIN) alternative under the following conditions: 
- the join is on two or more columns 
- both tables in the join have an index with leading, non-bound 
key columns that participate in the join 
- one or more leading columns match in order of the join 
columns, but not all 
 
For example, consider the following query 
 
SELECT * 
FROM T1,T2 
WHERE T1.A=T2.A and T1.B=T2.B and T1.C=T2.C and T1.X=1; 
 
where index IX1 is defined on T1(X,A,C,B) and index IX2 is 
defined on T2(A,B,C).  The column T1.X is bound to the constant 
1 as a result of the predicate "T1.X=1" so for the NLJOIN with 
IX1 access on the outer and IX2 access on the inner, the leading 
non-bound columns for both indexes are referenced in the join 
predicate T1.A=T2.A, but the subsequent columns are not ordered 
in join column order.  Under these conditions, the optimizer 
might over estimate the cost of the NLJOIN alternative, 
favouring a possibly worse-performing HSJOIN alternative
Problem Summary:
**************************************************************** 
* USERS AFFECTED:                                              * 
* DB2 V9.7 FP 8 and below                                      * 
**************************************************************** 
* PROBLEM DESCRIPTION:                                         * 
* See Error Description                                        * 
**************************************************************** 
* RECOMMENDATION:                                              * 
* Upgrade to DB2 V9.7 Fixpack 9                                * 
****************************************************************
Local Fix:
Create an index on either table, ensuring that the key columns 
are in join order.  Referring to the example in the Error 
Description, this could be achieved by creating an index on 
T2(A,C,B).
available fix packs:
DB2 Version 9.7 Fix Pack 9 for Linux, UNIX, and Windows
DB2 Version 9.7 Fix Pack 9a for Linux, UNIX, and Windows
DB2 Version 9.7 Fix Pack 10 for Linux, UNIX, and Windows

Solution
First fixed in DB2 V9.7 Fixpack 9
Workaround
not known / see Local fix
BUG-Tracking
forerunner  : APAR is sysrouted TO one or more of the following: IC97984 IC97986 
follow-up : 
Timestamps
Date  - problem reported    :
Date  - problem closed      :
Date  - last modified       :
05.02.2013
17.12.2013
17.12.2013
Problem solved at the following versions (IBM BugInfos)
9.7.FP9
Problem solved according to the fixlist(s) of the following version(s)
9.7.0.9 FixList
9.7.0.9 FixList
This site uses cookies to make it easier for us to provide you with our services. By using our site you agree to the use of cookies.