home clear 64x64
en blue 200x116 de orange 200x116 info letter User
suche 36x36
Neueste VersionenFixList
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
Haben Sie Probleme? - Kontaktieren Sie uns.
Kostenlos registrieren anmeldung-x26
Kontaktformular kontakt-x26

DB2 - Problembeschreibung

Problem IC68978 Status: Geschlossen

AVOID EXPANDING CARTESIAN JOIN PRODUCED BY AUTOMATICALLY REWRITING MULTIPLE
LEVEL CORRELATION IN DPF

Produkt:
DB2 FOR LUW / DB2FORLUW / 950 - DB2
Problembeschreibung:
In DPF DB2 compiler can transform correlated subquery to 
semijoin in order to improve query performance. If a group-by 
subquery (called subQL1) and this subquery's subquery (called 
subQL2) both reference some (not necessarily the same) column 
from its outer block (called outBlock), and if the subquery has 
at least one join table (called noCorrJoinTab) that has no join 
predicate to the outer block, DB2 may rewrite the query to such 
semi-join that includes a SELECT DISTINCT common table 
expression (CSE) that has Cartesian join on noCorrJoinTab. 
An example query is: 
select c1, c2, maxb5 
from c, 
table  (select max(b5) maxb5 
        from a, b 
        where a1 = b1 and 
              b2 = c1 and 
              a1 = (select max(b4) from b where b3 = c2) ) as t; 
subQL1 = "select max(b5) maxb5 from a, b where a1 = b1 and b2 = 
c1 and a1 = (select max(b4) from b where b3 = c2)" 
subQL2 = "select max(b4) from b where b3 = c2" 
outBlock = table c 
noCorrJoinTab = table a 
In db2exfmt explain plan file, the optimized statement show a 
SELECT DISTINCT CSE with Cartesian join on table a. 
The fix will resolve the expanding Cartesian join. It splits CSE 
and hence prevents TEMP in the query access plan. It may also 
access up to one row from the Cartesian join table so that the 
expanding Cartesian join is avoided.
Problem-Zusammenfassung:
In DPF DB2 compiler can transform correlated subquery to 
semijoin in order to improve query performance. If a group-by 
subquery (called subQL1) and this subquery's subquery (called 
subQL2) both reference some (not necessarily the same) column 
from its outer block (called outBlock), and if the subquery has 
at least one join table (called noCorrJoinTab) that has no join 
predicate to the outer block, DB2 may rewrite the query to such 
semi-join that includes a SELECT DISTINCT common table 
expression (CSE) that has Cartesian join on noCorrJoinTab. 
An example query is: 
select c1, c2, maxb5 
from c, 
table  (select max(b5) maxb5 
        from a, b 
        where a1 = b1 and 
              b2 = c1 and 
              a1 = (select max(b4) from b where b3 = c2) ) as t; 
subQL1 = "select max(b5) maxb5 from a, b where a1 = b1 and b2 = 
c1 and a1 = (select max(b4) from b where b3 = c2)" 
subQL2 = "select max(b4) from b where b3 = c2" 
outBlock = table c 
noCorrJoinTab = table a 
In db2exfmt explain plan file, the optimized statement show a 
SELECT DISTINCT CSE with Cartesian join on table a. 
The fix will resolve the expanding Cartesian join. It splits CSE 
and hence prevents TEMP in the query access plan. It may also 
access up to one row from the Cartesian join table so that the 
expanding Cartesian join is avoided.
Local-Fix:
verfügbare FixPacks:
DB2 Version 9.5 Fix Pack 8 for Linux, UNIX, and Windows
DB2 Version 9.5 Fix Pack 9 for Linux, UNIX, and Windows
DB2 Version 9.5 Fix Pack 10 for Linux, UNIX, and Windows

Lösung
apar IC68978 
fixed >= fpk8
Workaround
keiner bekannt / siehe Local-Fix
Weitere Daten
Datum - Problem gemeldet    :
Datum - Problem geschlossen :
Datum - der letzten Änderung:
02.06.2010
30.06.2011
30.06.2011
Problem behoben ab folgender Versionen (IBM BugInfos)
Problem behoben lt. FixList in der Version
9.5.0.8 FixList