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 IC94844 Status: Closed

ADMIN_MOVE_TABLE MIGHT RETURN SQL2103N RC=17 IF TARGET PRIMARY KEY INDEX DO
NOT MATCH SOURCE PRIMARY KEY INDEX

product:
DB2 FOR LUW / DB2FORLUW / 970 - DB2
Problem description:
ADMIN_MOVE_TABLE might return SQL2103N rc=17 if PRIMARY Key 
indexes do not match. 
This can occur if there are UNIQUE Indexes created on the source 
table with the 
same columns, but different order. 
 
eg. 
 
$ db2 "create table db2inst1.tab1(c1 int not null, c2 int not 
null)" 
DB20000I  The SQL command completed successfully. 
 
$ db2 "create unique index db2inst1.indx1 on 
db2inst1.tab1(c1,c2)" 
DB20000I  The SQL command completed successfully. 
 
$ db2 "create unique index db2inst1.indx2 on 
db2inst1.tab1(c2,c1)" 
DB20000I  The SQL command completed successfully. 
 
$ db2 "alter table db2inst1.tab1 add primary key(c2,c1)" 
SQL0598W  Existing index "DB2INST1.INDX1" is used as the index 
for the primary 
key or a unique key.  SQLSTATE=01550 
 
$ db2 "select substr(indname,1,30), uniquerule from 
syscat.indexes where tabname='TAB1'" 
1                              UNIQUERULE 
------------------------------ ---------- 
INDX1                          P 
INDX2                          U 
 
  2 record(s) selected. 
 
We could look to use either INDX1 or INDX2 for the Primary Key 
Index. 
 
This is working as design on the ALTER TABLE statement: 
 
See topic: 
Database administration > Administration concepts > Database 
objects > Constraints 
 
Reuse of indexes with unique or primary key constraints 
 
If you use the ALTER TABLE command to add a unique or primary 
key constraint to a partitioned table with a partitioned index, 
depending on the indexes that already exist, one might be 
altered to enforce the new constraint, or a new one might be 
created. 
 
When you run the ALTER TABLE statement to add or change a unique 
or primary key for a table, a check is performed to determine 
whether any existing index matches the unique or primary key 
being defined (INCLUDE columns are ignored). An index definition 
matches if it identifies the same set of columns, regardless of 
the order or the direction (for example ASC/DESC) of the 
columns. 
 
In the case of partitioned tables that have partitioned, 
non-unique indexes, if the index columns of the table being 
altered are not included among the columns that form the 
partition key, the index will not be considered a matching 
index. 
 
If the table does have a matching index definition, it will 
changed to be a UNIQUE index if it wasn't one already, and will 
marked as required by the system. If the table has more than one 
existing index that matches, then an existing unique index is 
selected. If there is more than one matching unique index, or if 
there are more than one matching non-unique indexes and no 
matching unique indexes, then a partitioned index is favoured. 
Otherwise the selection of an index is arbitrary. 
 
If no matching index is found, then a unique bidirectional index 
is automatically created for the columns.
Problem Summary:
**************************************************************** 
* USERS AFFECTED:                                              * 
* All Platforms                                                * 
**************************************************************** 
* PROBLEM DESCRIPTION:                                         * 
* See Error Description                                        * 
**************************************************************** 
* RECOMMENDATION:                                              * 
* Upgrade to v9.7 Fixpack 9 or higher                          * 
****************************************************************
Local Fix:
Look to have only one INDEX that matches the PRIMARY KEY on the 
source table when using ADMIN_MOVE_TABLE.
available fix packs:
DB2 Version 9.7 Fix Pack 9 for Linux, UNIX, and Windows
DB2 Version 9.7 Fix Pack 9a for Linux, UNIX, and Windows
DB2 Version 9.7 Fix Pack 10 for Linux, UNIX, and Windows

Solution
First Fixed in v9.7 Fixpack 9
Workaround
not known / see Local fix
BUG-Tracking
forerunner  : APAR is sysrouted TO one or more of the following: IC94880 IC94881 
follow-up : 
Timestamps
Date  - problem reported    :
Date  - problem closed      :
Date  - last modified       :
13.08.2013
30.12.2013
30.12.2013
Problem solved at the following versions (IBM BugInfos)
9.7.FP9
Problem solved according to the fixlist(s) of the following version(s)
9.7.0.9 FixList
9.7.0.9 FixList