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 IC91289 Status: Geschlossen

ORACLE WRAPPER LEAKS MEMORY WHEN ITERATIVELY EXECUTES DYNAMIC IUD
STATEMENTS IN A PACKAGE

Produkt:
DB2 FOR LUW / DB2FORLUW / A10 - DB2
Problembeschreibung:
When some IUD(INSERT/UPDATE/DELETE) statements are executed 
against Oracle nicknames iteratively in a package, the 
statements contain some host variables, and there is no COMMIT 
operation between each IUD, Oracle Wrapper may leak memory. 
 
The size of leaked memory is approximately equal to: (Number of 
Fixed-length host variables) * 2 * (Number of IUDs) bytes. 
 
The cause of memory leak is that, some assistant storages are 
not cleaned up properly among reuses of an opened remote 
statement object. 
 
You can reproduce memory leak by following procedure. Turn off 
AUTOCOMMIT before running: 
 
CREATE PROCEDURE TP () 
  SPECIFIC TP 
  LANGUAGE SQL 
  NOT DETERMINISTIC 
  EXTERNAL ACTION 
  MODIFIES SQL DATA 
  CALLED ON NULL INPUT 
  INHERIT SPECIAL REGISTERS 
BEGIN 
 
DECLARE C1V   VARCHAR(48); 
DECLARE DV   VARCHAR(48); 
DECLARE FLAG     INTEGER; 
 
SET FLAG=0; 
SET DV='AAA'; 
 
LOOP_IUD: LOOP 
 
DELETE FROM nickname1 WHERE C1=DV; 
INSERT INTO nickname2 VALUES(C1V); 
 
SET FLAG = FLAG + 1; 
  IF (FLAG = 1000) THEN 
        LEAVE LOOP_IUD; 
  END IF; 
END LOOP LOOP_IUD; 
COMMIT; 
 
END@ 
 
NOTE: nickname1 and nickname2 are two nicknames pointing to 
Oracle tables on the same Oracle data source. 
 
This memory leak usually happens in a Q Replication 
scenario(target is Oracle): 
1. QApply program tries to INSERT/UPDATE/DELETE target table in 
Oracle, 
2. But the INSERT/UPDATE/DELETE operation fails (because of 
conflicting key on an INSERT, or NOTFOUND on a DELETE/UPDATE), 
3. So QApply program inserts the IBMQREP_EXCEPTIONS table with 
the SQL code and other information for row changes that could 
not be applied. 
4. QApply program continues to INSERT/UPDATE/DELETE target table 
in Oracle. 
 
The memory leak happens at 3. Normally the memory leak is not 
obvious since QApply program does not have to inserts the 
IBMQREP_EXCEPTIONS table so frequently.
Problem-Zusammenfassung:
**************************************************************** 
* USERS AFFECTED:                                              * 
* The user is running oracle wrapper.                          * 
**************************************************************** 
* PROBLEM DESCRIPTION:                                         * 
* See Error Description                                        * 
**************************************************************** 
* RECOMMENDATION:                                              * 
* Upgrade to Federation Server v10.1 fp3.                      * 
****************************************************************
Local-Fix:
No local fix. A possible workaround is COMMIT after each IUD 
statement.
verfügbare FixPacks:
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

Lösung
The problem was firstly fixed on Federation Server v10.1 fp3.
Workaround
keiner bekannt / siehe Local-Fix
Weitere Daten
Datum - Problem gemeldet    :
Datum - Problem geschlossen :
Datum - der letzten Änderung:
03.04.2013
03.10.2013
03.10.2013
Problem behoben ab folgender Versionen (IBM BugInfos)
Problem behoben lt. FixList in der Version
10.1.0.3 FixList
10.1.0.3 FixList