DB2 FOR LUW / DB2FORLUW / A10 - DB2

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.

**************************************************************** 
* USERS AFFECTED:                                              * 
* The user is running oracle wrapper.                          * 
**************************************************************** 
* PROBLEM DESCRIPTION:                                         * 
* See Error Description                                        * 
**************************************************************** 
* RECOMMENDATION:                                              * 
* Upgrade to Federation Server v10.1 fp3.                      * 
****************************************************************

No local fix. A possible workaround is COMMIT after each IUD 
statement.

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
 

The problem was firstly fixed on Federation Server v10.1 fp3.

not known / see Local fix

Date  - problem reported    :
Date  - problem closed      :
Date  - last modified       :

03.04.2013
03.10.2013
03.10.2013