|
Problem IT16882
|
Status: Closed |
DB2 BLU QUERY CAN END UP WITH WRONG JOIN ORDER SO THAT HASH JOINIS BUILDING ON LARGE TABLE |
| product: |
DB2 FOR LUW / DB2FORLUW / A50 - DB2 |
| Problem description: |
A BLU query can be optimized with a suboptimal plan so that the
hash join order is flipped and the hash is building on a very
large intermediate table.
This is a very specific case caused by an Effectively Cartesian
join of the fact table in the query. This can be seen in explain
with filter factor = 1, i.e.:
60) Predicate used in Join,
Comparison Operator: Equal (=)
Subquery Input Required: No
Filter Factor: 1
The query may eventually fail with SQL0955 due to out of
SORTHEAP memory.
A better plan which avoids this problem is picked up with
optimization level 9. This should already happen with default
optimization level 5. |
| Problem Summary: |
****************************************************************
* USERS AFFECTED: *
* ALL *
****************************************************************
* PROBLEM DESCRIPTION: *
* See Error Description *
****************************************************************
* RECOMMENDATION: *
* Upgrade to Db2 10.5 Fix Pack 9 or higher *
**************************************************************** |
| Local Fix: |
Use optimization level 9 |
| Solution |
First fixed in Db2 10.5 Fix Pack 9 |
| Workaround |
not known / see Local fix |
| Timestamps |
Date - problem reported :
Date - problem closed :
Date - last modified :
| 02.09.2016
29.09.2017
29.09.2017 |
| Problem solved at the following versions (IBM BugInfos) |
9.0.
|
| Problem solved according to the fixlist(s) of the following version(s) |
