DB2 FOR LUW / DB2FORLUW / 950 - DB2

When the target table is a (non-MDC) Range Partitioned table, 
and Load is invoked with the COPY YES option, in rare timing 
scenarios it's possible for the Load to trap (likely with 
sqluTransformMergeRequestio or sqluTransformMergeFSCRRequest in 
the stack), or it's possible for the Load to panic with a 
BADPAGE error (likely with similar functions in the stack). The 
exact stack that is generate may differ, but will involve the 
Load 'db2lbm' or 'db2lrid' edus. 
 
This is caused by a rare timing scenario where both the db2lbm 
and db2lrid EDUs are manipulating the same Load data-page 
concurrently. 
 
The problem is more likely to occur when the number of ranges is 
very large.

**************************************************************** 
* USERS AFFECTED:                                              * 
* BAD PAGE DETECTED IN SQLB_VERIFY_PAGE WHILE EXEUCTING        * 
* LOADAGAINST A RANGE PARTITIONED TABLE                        * 
**************************************************************** 
* PROBLEM DESCRIPTION:                                         * 
* When the table is a (non-MDC) RP table, and Load has theCOPY * 
* YES flag, extents are only sent to the copy image ifthey are * 
* either completely full, or at the end of Load Phasewe are    * 
* flushing all the partially filled extents. In thelatter      * 
* scenario, some special logic exists to send thesepartially   * 
* filled extents over to a BufferManipulator EDU tofirst to    * 
* merge the partially filled extent with any pages incontainer * 
* that were previously victimized (ie. MDC/RP Loadcaching      * 
* algorithm) and then over to the MediaWriter EDUwithout       * 
* actually writing the extent to container (since itwas        * 
* previously flushed to container). This logic                 * 
* willinadvertently recycle a transfer-buffer twice, and if    * 
* enoughranges exist the transfer-buffer might be reused by    * 
* theRidder twice (whilst one of the transfer-buffers has not  * 
* yetbeen flushed out). When this happens we can see           * 
* differenttypes of errors such as bad-pages, or even          * 
* traps.The problem is exacerbated by the fact that the number * 
* of RPranges was so huge (I know this because the             * 
* extent-cachingwas automatically disabled for the table (the  * 
* 'cachingdisabled at startup' message in the db2diag.log)     * 
* because ofthis), so the number of partially filled extents   * 
* flushed atthe end of Load Phase was huge, increasing the     * 
* probabilityof encountering it.                               * 
**************************************************************** 
* RECOMMENDATION:                                              * 
* Any user encountering this APAR should upgrade to This       * 
* APARis fixed in DB2 LUW Version 9.5 fixpack 6                * 
****************************************************************

No Local Fix.

DB2 Version 9.5 Fix Pack 6a for Linux, UNIX, and Windows
 DB2 Version 9.5 Fix Pack 7 for Linux, UNIX, and Windows
 DB2 Version 9.5 Fix Pack 8 for Linux, UNIX, and Windows
 DB2 Version 9.5 Fix Pack 9 for Linux, UNIX, and Windows
 DB2 Version 9.5 Fix Pack 10 for Linux, UNIX, and Windows
 

This APAR is fixed in DB2 LUW Version 9.5 fixpack 6

not known / see Local fix

forerunner  : APAR is sysrouted TO one or more of the following: IC63845 IC64633 IC69146 JR36829 IC69148 
follow-up : 

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

02.09.2009
13.09.2010
13.09.2010

9.5.FP6