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 IC84192 Status: Geschlossen

COLUMN GROUP STATISTICS NOT ALWAYS APPLIED TO CYCLE OF 3 OR MORE JOINS

Produkt:
DB2 FOR LUW / DB2FORLUW / A10 - DB2
Problembeschreibung:
Column Group Statistics (CGS) might not be considered by the DB2 
optimizer when accounting for statistical correlation in a cycle 
of 3 or more tables due to inconclusive parent and child 
determination. For the optimizer to correct for statistical 
correlation using CGS, one table must have a column cardinality 
that is greater than or equal  to the other table for all 
columns involved in the CGS, and it must have a high2key/low2key 
range for each column that is inclusive of the other table. 
 
For non-cyclic joins, these conditions are not critical; 
however, when 3 or more tables are involved in a cycle of joins, 
if these conditions are not met for 1 pair of tables in the 
cycle, the optimizer might end up correcting for statistical 
correlation for some of the joins, and not others.  This can 
lead the optimizer to favour a join between the tables that have 
not had their cardinality corrected. 
 
For example, consider the query: 
 
select * from T1, T2, T3 where T1.C1 = T2.D1 and 
T1.C1 = T3.E3 and T2.D1 = T3.E1 and T1.C2 = T2.D2 and T1.C2 = 
T3.E3 and T2.D2 = T3.E3 
 
with statistics for the 3 tables and their columns as follows: 
 
Table.Column  Col Card  Hi2Key Lo2Key 
T1.C1              100              99      1 
T1.C2              10                  9      1 
T2.D1              50                74    26 
T2.D2                4                  7      4 
T3.E1                40                89    41 
T3.E3                  5                4      1 
 
In the example, T1 has a higher column cardinality and inclusive 
Hi2Key, Lo2Key when comparing T1.C1 = T2.D2 and T1.C1 = T3.E3, 
and when comparing T1.C2 = T2.D2 and T1.C2 = T2.E2. The problem 
is observed when comparing T2.D1 = T3.E1 and T2.D2 = T3.D3 where 
the column cardinalities and the {Hi2Key, Lo2Key} range are 
conflicting. Under these conditions, the optimizer will not 
account for statistical correlation for the T2/T3 join, leading 
to the optimizer potentially favouring this join. 
 
The fix is activated using the DB2 environment variable: 
DB2_CORRELATED_PREDICATES='FORCE_CGS'
Problem-Zusammenfassung:
**************************************************************** 
* USERS AFFECTED:                                              * 
* All DB2 for LUW users with complex joins                     * 
**************************************************************** 
* PROBLEM DESCRIPTION:                                         * 
* Column Group Statistics (CGS) might not be considered by the * 
* DB2                                                          * 
* optimizer when accounting for statistical correlation in a   * 
* cycle                                                        * 
* of 3 or more tables due to inconclusive parent and child     * 
* determination. For the optimizer to correct for statistical  * 
* correlation using CGS, one table must have a column          * 
* cardinality                                                  * 
* that is greater than or equal  to the other table for all    * 
* columns involved in the CGS, and it must have a              * 
* high2key/low2key                                             * 
* range for each column that is inclusive of the other table.  * 
*                                                              * 
* For non-cyclic joins, these conditions are not critical;     * 
* however, when 3 or more tables are involved in a cycle of    * 
* joins,                                                       * 
* if these conditions are not met for 1 pair of tables in the  * 
* cycle, the optimizer might end up correcting for statistical * 
* correlation for some of the joins, and not others.  This can * 
* lead the optimizer to favour a join between the tables that  * 
* have                                                         * 
* not had their cardinality corrected.                         * 
*                                                              * 
* For example, consider the query:                             * 
*                                                              * 
* select * from T1, T2, T3 where T1.C1 = T2.D1 and             * 
* T1.C1 = T3.E3 and T2.D1 = T3.E1 and T1.C2 = T2.D2 and T1.C2  * 
* =                                                            * 
* T3.E3 and T2.D2 = T3.E3                                      * 
*                                                              * 
* with statistics for the 3 tables and their columns as        * 
* follows:                                                     * 
*                                                              * 
* Table.Column  Col Card  Hi2Key Lo2Key                        * 
* T1.C1              100              99      1                * 
* T1.C2              10                  9      1              * 
* T2.D1              50                74    26                * 
* T2.D2                4                  7      4             * 
* T3.E1                40                89    41              * 
* T3.E3                  5                4      1             * 
*                                                              * 
* In the example, T1 has a higher column cardinality and       * 
* inclusive                                                    * 
* Hi2Key, Lo2Key when comparing T1.C1 = T2.D2 and T1.C1 =      * 
* T3.E3,                                                       * 
* and when comparing T1.C2 = T2.D2 and T1.C2 = T2.E2. The      * 
* problem                                                      * 
* is observed when comparing T2.D1 = T3.E1 and T2.D2 = T3.D3   * 
* where                                                        * 
* the column cardinalities and the {Hi2Key, Lo2Key} range are  * 
* conflicting. Under these conditions, the optimizer will not  * 
* account for statistical correlation for the T2/T3 join,      * 
* leading                                                      * 
* to the optimizer potentially favouring this join.            * 
*                                                              * 
* The fix is activated using the DB2 environment variable:     * 
* DB2_CORRELATED_PREDICATES='FORCE_CGS'                        * 
**************************************************************** 
* RECOMMENDATION:                                              * 
* Upgrade the DB2 for Linux Unix and Windows server to Version * 
* 9.5 Fixpack 10 or higher.                                    * 
****************************************************************
Local-Fix:
verfügbare FixPacks:
DB2 Version 10.1 Fix Pack 1 for Linux, UNIX, and Windows
DB2 Version 10.1 Fix Pack 2 for Linux, UNIX, and Windows
DB2 Version 10.1 Fix Pack 3 for Linux, UNIX, and Windows
DB2 Version 10.1 Fix Pack 4 for Linux, UNIX, and Windows
DB2 Version 10.1 Fix Pack 3a for Linux, UNIX, and Windows
DB2 Version 10.1 Fix Pack 6 for Linux, UNIX, and Windows

Lösung
Upgrade the DB2 for Linux Unix and Windows server to Version 9.5 
Fixpack 10 or higher.
Workaround
keiner bekannt / siehe Local-Fix
Weitere Daten
Datum - Problem gemeldet    :
Datum - Problem geschlossen :
Datum - der letzten Änderung:
13.06.2012
05.11.2012
05.11.2012
Problem behoben ab folgender Versionen (IBM BugInfos)
9.5.,
9.5.FP10
Problem behoben lt. FixList in der Version
10.1.0.1 FixList
10.5.0.1 FixList