DB2 FOR LUW / DB2FORLUW / A10 - DB2

Db2 may crash with a signal #11 during a query compile with the 
following  stack traceback: 
 
sqlrxcp2 
sqlzSortZvalueArrayCheckPresorted 
sqlzSortZvalueArray 
sqlngBuildInSetBinaryOp 
sqlngBuildInList 
sqlng_process_parse_tree_node 
sqlng_process_BF_node 
sqlng_walk_BF_chain 
... 
 
In the above example, the query compiler is processing an 
in-list that contains constant literals, for example: 
...where col1 in (1,2,3) 
 
The in-list example is the case where the problem was first 
observed, but it may be possible that other symptoms/flavours of 
this same issue might happen for other query operations, and 
it's not limited to just an in-list. 
 
Specifically, the problem is a logic flaw when the compiler is 
generating 
a plan that features a hsjn whose left-side (probe) logic has 
been pushed into 
the inner (right side) of a nested loop join.  For example: 
 
        HSJN 
      /      \ 
   NLJN     scan 
  /    \ 
scan  scan 
 
With the above style of plan, if the following conditions are 
true: 
- At least one column from the left side (outer) of the NLJN is 
included in the payload (non-join-key) columns 
   of the left (probe) side of the HSJN 
- This mentioned column is a constant literal value 
- This same constant is referenced somewhere else in the plan 
(such as the in-list example) 
 
...then the problem may occur.

**************************************************************** 
* USERS AFFECTED:                                              * 
* All                                                          * 
**************************************************************** 
* PROBLEM DESCRIPTION:                                         * 
* See Error Description                                        * 
**************************************************************** 
* RECOMMENDATION:                                              * 
* Upgrade to Version 10.1 Fix Pack 4                           * 
****************************************************************

Changing the query or plan to remove the above conditions can 
avoid the issue. 
For example, at optimization level 3, HSJN will not be 
considered by the optimizer and it can avoid the problem.

First fixed in Version 10.1 Fix Pack 4

not known / see Local fix

Date  - problem reported    :
Date  - problem closed      :
Date  - last modified       :

08.04.2014
13.07.2015
13.07.2015