DB2 - Problem description
Problem IT00605 | Status: Closed |
DB2 OPTIMIZER CAN CHOOSE A NON-OPTIMAL BLOCK INDEX TO ACCESS MDC TABLE WHEN THE BLOCK INDEXES HAVE ONLY 1 LEVEL | |
product: | |
DB2 FOR LUW / DB2FORLUW / A50 - DB2 | |
Problem description: | |
When a MDC table has more than one dimensions, and when the block indexes have only 1 level, the optimizer might choose a block index access that applies a predicate as index sargable rather than a more efficient block index access that applies the predicate as start-stop keys. For example, consider a query that references a MDC table that is organized by 3 columns (C1,C2,C3), and includes the predicate C2=1. The predicate is applied as index sargable on the index access of the block index on (C1, C2, C3) (refer to hereafter as index A) whereas it is applied as a start-stop key on the index access of the block index on (C2) (refer to hereafter as index B). The optimizer might choose an access path using index A rather than index B. | |
Problem Summary: | |
**************************************************************** * USERS AFFECTED: * * All * **************************************************************** * PROBLEM DESCRIPTION: * * See Error Description * **************************************************************** * RECOMMENDATION: * * Upgrade to DB2 Version 10.5 Fix Pack 4 * **************************************************************** | |
Local Fix: | |
Use optimization profile to force the desired index access. | |
available fix packs: | |
DB2 Cancun Release 10.5.0.4 (also known as Fix Pack 4) for Linux, UNIX, and Windows | |
Solution | |
First fixed in DB2 Version 10.5 Fix Pack 4 | |
Workaround | |
not known / see Local fix | |
Timestamps | |
Date - problem reported : Date - problem closed : Date - last modified : | 28.03.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 |