DB2 - Problem description
| Problem IC72243 | Status: Closed |
Optimizer may choose a non-optimal plan for queries using FETCH FIRST ROWS ONLY caluse, which can cause performance degradation. | |
| product: | |
DB2 FOR LUW / DB2FORLUW / 970 - DB2 | |
| Problem description: | |
Optimizer may choose a non-optimal plan for queries using FETCH
FIRST ROWS ONLY (FFNR) caluse, which can lead to performance
degradation. This plan causes a large stream of data to be
broadcasted across partitions. Users will find this evident in
the query access plan, which will show the BTQ operation
broadcasting large stream of data as following:
/--------
1.07181e+07
BTQ
( 13)
125531
31015.2
|
2.67952e+06
IXSCAN
( 14)
123504
31015.2
|
2.67952e+06
INDEX: <name of the index>
In this example, aprox 1.07x10^7 rows are being broadcasted
across partitions. This leads to poor performance. | |
| Problem Summary: | |
USERS AFFECTED: =============== Customer using version 9.5 and above on all platforms. PROBLEM DESCRIPTION: ==================== Queries using FIRST FIRST ROWS ONLY (FFNR) clause may experience performance problem after migrating from version 8 to version 9. The APAR can be confirmed by checking the query access graph. If a BTQ operation is seen broadcasting large stream of data, it may point to this APAR. RECOMMENDATION: =============== There is currently no workaround other than not using the FFNR clause. | |
| Local Fix: | |
| available fix packs: | |
DB2 Version 9.7 Fix Pack 4 for Linux, UNIX, and Windows | |
| Solution | |
Problem is first fixed in version 9.7 Fixpack 4. | |
| Workaround | |
There is currently no workaround other than not using the FFNR clause. | |
| Timestamps | |
Date - problem reported : Date - problem closed : Date - last modified : | 27.10.2010 03.05.2011 03.05.2011 |
| Problem solved at the following versions (IBM BugInfos) | |
9.7.FP4 | |
| Problem solved according to the fixlist(s) of the following version(s) | |
| 9.7.0.4 |
|