home clear 64x64
en blue 200x116 de orange 200x116 info letter User
suche 36x36
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 IC86029 Status: Closed

CREATING A UNIQUE GLOBAL INDEX ON A TABLE WITH DETACHED PARTITIO N AND
DEPENDANT MQT MIGHT LEAD TO INCORRECT RESULT AFTER REFRESH

product:
DB2 FOR LUW / DB2FORLUW / A10 - DB2
Problem description:
After detaching a partition from a range partitioned table with 
a dependent materialized query table (MQT), a unique global 
index might get created. 
If a unique global index gets created and the detached partition 
has any duplicates, refreshing the MQT might lead to incorrect 
results. 
 
The following commands illustrate how refreshing the MQT might 
lead to incorrect results: 
 
create table t1(rk int not null, uk int not null) partition by 
range(rk) (starting 0 ending 10001 every 1000); 
insert into t1 values(1,1),(2,1); 
 
create table t2 (uk int not null); 
insert into t2 values(1); 
 
create table m1 as (select t1.uk, count(*) as count from t1, t2 
where t1.uk=t2.uk group by t1.uk) data initially deferred 
refresh immediate; 
refresh table m1; 
 
select * from m1; 
 
UK          COUNT 
----------- ----------- 
          1           2 
 
  1 record(s) selected. 
 
alter table t1 detach partition part0 into part0; 
create unique index t1_uk on t1(uk) not partitioned; 
refresh table m1; 
 
select * from m1; 
 
UK          COUNT 
----------- ----------- 
          1           1 
 
  1 record(s) selected. 
 
To identify the MQTs that are affected by this problem, perform 
the following steps: 
 
1) Record the current query optimization level and set it to 3 
by issuing the following commands: 
 
select current query optimization from sysibm.sysdummy1; 
set current query optimization 3; 
 
2) Verify if querying the MQT and the MQT query definition 
return different result set by issuing the following commands: 
 
(mqt_query_definition) except all select * from mqt 
select * from mqt except all (mqt_query_definition) 
 
Using the previous example, the resultant queries are as 
follows: 
 
(select t1.uk, count(*) as count from t1, t2 where t1.uk=t2.uk 
group by t1.uk) except all select * from m1 
 
UK          COUNT 
----------- ----------- 
 
  0 record(s) selected. 
 
 
select * from m1 except all (select t1.uk, count(*) as count 
from t1, t2 where t1.uk=t2.uk group by t1.uk) 
 
UK          COUNT 
----------- ----------- 
          1           1 
 
  1 record(s) selected. 
 
If either of the EXCEPT ALL queries return any record, then that 
MQT is 
impacted and is returning incorrect result.
Problem Summary:
**************************************************************** 
* USERS AFFECTED:                                              * 
* All users                                                    * 
**************************************************************** 
* PROBLEM DESCRIPTION:                                         * 
* See Error Description                                        * 
**************************************************************** 
* RECOMMENDATION:                                              * 
* Upgrade to DB2 version 10.1.0.2.                             * 
****************************************************************
Local Fix:
Run "REFRESH TABLE <mqt_name> NOT INCREMENTAL" to do a full 
refresh on the MQT
available fix packs:
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

Solution
The problem is first fixed in DB2 version 10.1.0.2.
Workaround
not known / see Local fix
Timestamps
Date  - problem reported    :
Date  - problem closed      :
Date  - last modified       :
21.08.2012
07.12.2012
07.12.2012
Problem solved at the following versions (IBM BugInfos)
Problem solved according to the fixlist(s) of the following version(s)
10.1.0.2 FixList
10.5.0.2 FixList