Latest versionsfixlist
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
Have problems? - contact us.
Register for free anmeldung-x26
Contact form kontakt-x26

DB2 - Problem description

Problem IC67155 Status: Closed

DB2EXFMT TAKES A LONG TIME TO COMPLETE ( 5+ HOURS) AFTER RUNNING A QUERY
THAT LOADS THE LARGE AMOUNT OF DATA INTO EXPLAIN TABLES.

product:
DB2 FOR LUW / DB2FORLUW / 980 - DB2
Problem description:
db2exfmt, with grapher (-g) option, takes a long time to 
complete ( over 5 hours) after running a query that loaded the 
large amount of data into explain tables.
Problem Summary:
**************************************************************** 
* USERS AFFECTED:                                              * 
* ALL                                                          * 
**************************************************************** 
* PROBLEM DESCRIPTION:                                         * 
* db2exfmt, with grapher (-g) option, takes a long time        * 
* tocomplete ( over 5 hours) after running a query that        * 
* loadedthelarge amount of data into explain tables.           * 
**************************************************************** 
* RECOMMENDATION:                                              * 
* Work around:1. First Create the following three              * 
* indexes:CREATE INDEX OPR_I2 on                               * 
* EXPLAIN_OPERATOR(EXPLAIN_TIME,EXPLAIN_LEVEL, STMTNO, SECTNO, * 
* explain_requester,source_name,source_schema, source_version, * 
* OPERATOR_ID, operator_type,total_cost, io_cost)CREATE INDEX  * 
* STRM_I2 on  EXPLAIN_STREAM(EXPLAIN_TIME,EXPLAIN_LEVEL,       * 
* STMTNO, SECTNO, explain_requester,source_name,source_schema, * 
* source_version, target_id, source_id,stream_count)CREATE     * 
* INDEX ARG_I2 on EXPLAIN_ARGUMENT(EXPLAIN_TIME,EXPLAIN_LEVEL, * 
* STMTNO, SECTNO, OPERATOR_ID, argument_type)2. Then, for the  * 
* at least those 3 explain tables, run'runstatson table        * 
* xxx.explain_yyy and detailed indexes all' rightafterrunning  * 
* query that loads large amount of data into thoseexplain      * 
* tables.                                                      * 
****************************************************************
Local Fix:
Work around: 
 
1. First Create the following three indexes: 
 
CREATE INDEX OPR_I2 on    EXPLAIN_OPERATOR(EXPLAIN_TIME, 
EXPLAIN_LEVEL, STMTNO, SECTNO, explain_requester, source_name, 
source_schema, source_version, OPERATOR_ID, operator_type, 
total_cost, io_cost) 
 
CREATE INDEX STRM_I2 on  EXPLAIN_STREAM(EXPLAIN_TIME, 
EXPLAIN_LEVEL, STMTNO, SECTNO, explain_requester, source_name, 
source_schema, source_version, target_id, source_id, 
stream_count) 
 
CREATE INDEX ARG_I2 on EXPLAIN_ARGUMENT(EXPLAIN_TIME, 
EXPLAIN_LEVEL, STMTNO, SECTNO, OPERATOR_ID, argument_type) 
 
2. Then, for the at least those 3 explain tables, run 'runstats 
on table xxx.explain_yyy and detailed indexes all' right after 
running query that loads large amount of data into those 
explain tables.
available fix packs:
DB2 Version 9.8 Fix Pack 3 for Linux, UNIX, and Windows
DB2 Version 9.8 Fix Pack 4 for AIX and Linux
DB2 Version 9.8 Fix Pack 5 for AIX and Linux

Solution
First fixed in DB2 UDB Version 9.8 Fix Pack 3
Workaround
not known / see Local fix
Timestamps
Date  - problem reported    :
Date  - problem closed      :
Date  - last modified       :
12.03.2010
20.12.2010
20.12.2010
Problem solved at the following versions (IBM BugInfos)
9.8.FP3
Problem solved according to the fixlist(s) of the following version(s)
9.8.0.3 FixList