home clear 64x64
en blue 200x116 de orange 200x116 info letter User
suche 36x36
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 IC99122 Status: Closed

PERFORMANCE COULD BE POOR WHEN A SMALL NICKNAME JOINS A LARGE NICKNAME JOIN
RESULT

product:
DB2 FOR LUW / DB2FORLUW / A50 - DB2
Problem description:
Performance could be poor when a small table joins a large table 
join result, e.g. 
 
select * from small_nick a, (select * from large_nick1 ln1, 
large_nick2 ln2 where ln1.c = ln2.c) b where a.c = b.c 
 
where the join of ln1 and ln2 generates a large result set. The 
bad performance can be resulted from Optimizer fails to generate 
a optimal plan. This is because, the optimal plan is a NLJN with 
the large table as the inner side, and the join predicate is 
pushdown to remote server with a FILTER under SHIP of inner side 
to filter data fetched as much as possible, that is: 
           NLJN 
   /                  \ 
SHIP              SHIP 
 |                      | 
a                   FILTER 
                /                 \ 
              large_nick1    large_nick2 
 
However, due to limitation of Optimizer, a plan with the join 
predicate above the SHIP will be chosen, such a poor plan could 
be like: 
                  NLJN 
           /                 \ 
       SHIP             TBSCAN  <---join predicate is included 
here, right above the SHIP 
         |                    | 
         a                TEMP 
                              | 
                          SHIP 
                             | 
                         FILTER 
                             .... 
                       /                 \ 
                 large_nick1    large_nick2 
 
With such poor plan, all data from the two large nickames will 
be fetched, causing bad performance.
Problem Summary:
**************************************************************** 
* USERS AFFECTED:                                              * 
* Users who use Federation Server v10.5                        * 
**************************************************************** 
* PROBLEM DESCRIPTION:                                         * 
* See Error Description                                        * 
**************************************************************** 
* RECOMMENDATION:                                              * 
* Upgrade to Federation Server v10.5 fp4 or above              * 
****************************************************************
Local Fix:
available fix packs:
DB2 Cancun Release 10.5.0.4 (also known as Fix Pack 4) for Linux, UNIX, and Windows
DB2 Version 10.5 Fix Pack 9 for Linux, UNIX, and Windows

Solution
The problem is fixed in v10.5 fp4
Workaround
not known / see Local fix
Timestamps
Date  - problem reported    :
Date  - problem closed      :
Date  - last modified       :
03.02.2014
08.09.2014
08.09.2014
Problem solved at the following versions (IBM BugInfos)
Problem solved according to the fixlist(s) of the following version(s)
10.5.0.4 FixList