home clear 64x64
en blue 200x116 de orange 200x116 info letter User
suche 36x36
Neueste VersionenFixList
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
Haben Sie Probleme? - Kontaktieren Sie uns.
Kostenlos registrieren anmeldung-x26
Kontaktformular kontakt-x26

DB2 - Problembeschreibung

Problem IC84739 Status: Geschlossen

STATEMENTS REFERENCING ARRAY OR ROW TYPES CAN FAIL WITH SQL0901N IN DPF
ENVIRONMENTS

Produkt:
DB2 FOR LUW / DB2FORLUW / 970 - DB2
Problembeschreibung:
When an array or a row variable is referenced in a statement 
along with a table that spans multiple database partitions, it 
is possible for plan to be generated which attempts to ship the 
array or row variable across database partitions.  This will 
result in an SQL0901N error during compilation. 
 
For example, in this scenario the array subindex operation is 
evaluated on each partition and the result (a row data type 
representing the array element) is shipped to the coordinator 
partition: 
 
create table t1 (c1 int, c2 int, c3 varchar(128)) 
DB20000I  The SQL command completed successfully. 
 
create type n1_row as row anchor row t1 
DB20000I  The SQL command completed successfully. 
 
create type n1_arr as n1_row array[varchar(100)] 
DB20000I  The SQL command completed successfully. 
 
create function foo () returns int 
begin 
 declare v1 n1_arr; 
 declare v2 n1_arr; 
 
 set v1('a') = v2[(select c3 from t1 where c1=2)]; 
 
 return 0; 
end 
DB21034E  The command was processed as an SQL statement because 
it was not a 
valid Command Line Processor command.  During SQL processing it 
returned: 
SQL0901N  The SQL statement failed because of a non-severe 
system error. 
Subsequent SQL statements can be processed.  (Reason "Bad dyn 
index. 
idx=4294956373 size=15 (off=3442197904)".)  LINE NUMBER=6. 
SQLSTATE=58004
Problem-Zusammenfassung:
**************************************************************** 
* USERS AFFECTED:                                              * 
* All                                                          * 
**************************************************************** 
* PROBLEM DESCRIPTION:                                         * 
* See Error Description                                        * 
**************************************************************** 
* RECOMMENDATION:                                              * 
* Upgrade to DB2 LUW version 9.7 fix pack 7.                   * 
****************************************************************
Local-Fix:
Remove the statement that is generating the SQL0901N error, or 
if possible, rewrite it to remove the reference to the table 
that resides on multiple partitions. 
 
For example, this statement in the ERROR DESCRIPTION scenario: 
 
set v1('a') = v2[(select c3 from t1 where c1=2)]; 
 
Can be split into two statements: 
 
set index = (select c3 from t1 where c1=2); 
set v1('a') = v2[index];
verfügbare FixPacks:
DB2 Version 9.7 Fix Pack 7 for Linux, UNIX, and Windows
DB2 Version 9.7 Fix Pack 8 for Linux, UNIX, and Windows
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

Lösung
Fix included in DB2 LUW version 9.7 fix pack 7. 
 
With this fix statements that would previously fail with 
SQL0901N will now succeed.
Workaround
See LOCAL FIX
Bug-Verfolgung
Vorgänger  : APAR is sysrouted TO one or more of the following: IC87912 
Nachfolger : 
Weitere Daten
Datum - Problem gemeldet    :
Datum - Problem geschlossen :
Datum - der letzten Änderung:
19.06.2012
20.10.2012
20.10.2012
Problem behoben ab folgender Versionen (IBM BugInfos)
9.7.FP7
Problem behoben lt. FixList in der Version
9.7.0.7 FixList