DB2 - Problem description
Problem IC80451 | Status: Closed |
OPTIMIZER'S ESTIMATED CARDINALITY INCORRECTLY DROPS AT TQ OPERATOR WHEN QUERY CONTAINS NODENUMBER PREDICATE | |
product: | |
DB2 FOR LUW / DB2FORLUW / 970 - DB2 | |
Problem description: | |
If a query contains a predicate on NODENUMBER which restricts to a single node (such as NODENUMBER(T1.C1) = <const>), the optimizer may incorrectly reduce the estimated cardinality at certain TQ operators in the access plan. This can potentially lead to a suboptimal plan choice. | |
Problem Summary: | |
**************************************************************** * USERS AFFECTED: * * Queries using a nodenumber predicate in a DPF envinronment * * may be impacted * **************************************************************** * PROBLEM DESCRIPTION: * * See Error Description * **************************************************************** * RECOMMENDATION: * * Upgrade to DB2 Version 9.7 Fix Pack 6 * **************************************************************** | |
Local Fix: | |
If the TQ cardinality drops at the TQ of a base table, replicating the base table may correct the cardinality, but this depends on the optimizer choosing to use the replicated table based on cost. | |
available fix packs: | |
DB2 Version 9.7 Fix Pack 6 for Linux, UNIX, and Windows | |
Solution | |
First fixed in DB2 Version 9.7 Fix Pack 6 | |
Workaround | |
not known / see Local fix | |
BUG-Tracking | |
forerunner : APAR is sysrouted TO one or more of the following: IC84497 follow-up : | |
Timestamps | |
Date - problem reported : Date - problem closed : Date - last modified : | 15.12.2011 07.06.2012 07.06.2012 |
Problem solved at the following versions (IBM BugInfos) | |
9.7.FP6 | |
Problem solved according to the fixlist(s) of the following version(s) | |
9.7.0.6 |