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

BAD PAGE DETECTED IN SQLB_VERIFY_PAGE WHILE EXEUCTING LOAD AGAINST A
RANGE PARTITIONED TABLE

product:
DB2 FOR LUW / DB2FORLUW / 910 - DB2
Problem description:
When the table is a (non-MDC) RP table, and Load has the COPY 
YES flag, extents are only sent to the copy image if they are 
either completely full, or at the end of Load Phase we are 
flushing all the partially filled extents. In the latter 
scenario, some special logic exists to send these partially 
filled extents over to a BufferManipulator EDU to first to merge 
the partially filled extent with any pages in container that 
were previously victimized (ie. MDC/RP Load caching algorithm) 
and then over to the MediaWriter EDU without actually writing 
the extent to container (since it was previously flushed to 
container). This logic will inadvertently recycle a 
transfer-buffer twice, and if enough ranges exist the 
transfer-buffer might be reused by the Ridder twice (whilst one 
of the transfer-buffers has not yet been flushed out). When this 
happens we can see different types of errors such as bad-pages, 
or even traps. 
 
The problem is exacerbated by the fact that the number of RP 
ranges was so huge (I know this because the extent-caching was 
automatically disabled for the table (the 'caching disabled at 
startup' message in the db2diag.log) because of this), so the 
number of partially filled extents flushed at the end of Load 
Phase was huge, increasing the probability of encountering it.
Problem Summary:
**************************************************************** 
* USERS AFFECTED:                                              * 
* Users loading data into a RANGE PARTITION table.             * 
**************************************************************** 
* PROBLEM DESCRIPTION:                                         * 
* BAD PAGE DETECTED IN SQLB_VERIFY_PAGE WHILE EXEUCTING LOAD   * 
* AGAINST A RANGE PARTITIONED TABLE                            * 
*                                                              * 
* When the table is a (non-MDC) RP table, and Load has the     * 
* COPY                                                         * 
* YES flag, extents are only sent to the copy image if they    * 
* are                                                          * 
* either completely full, or at the end of Load Phase we are   * 
* flushing all the partially filled extents. In the latter     * 
* scenario, some special logic exists to send these partially  * 
* filled extents over to a BufferManipulator EDU to first to   * 
* merge                                                        * 
* the partially filled extent with any pages in container that * 
*                                                              * 
* were previously victimized (ie. MDC/RP Load caching          * 
* algorithm)                                                   * 
* and then over to the MediaWriter EDU without actually        * 
* writing                                                      * 
* the extent to container (since it was previously flushed to  * 
* container). This logic will inadvertently recycle a          * 
* transfer-buffer twice, and if enough ranges exist the        * 
* transfer-buffer might be reused by the Ridder twice (whilst  * 
* one                                                          * 
* of the transfer-buffers has not yet been flushed out). When  * 
* this                                                         * 
* happens we can see different types of errors such as         * 
* bad-pages,                                                   * 
* or even traps.                                               * 
*                                                              * 
* The problem is exacerbated by the fact that the number of RP * 
*                                                              * 
* ranges was so huge (I know this because the extent-caching   * 
* was                                                          * 
* automatically disabled for the table (the 'caching disabled  * 
* at                                                           * 
* startup' message in the db2diag.log) because of this), so    * 
* the                                                          * 
* number of partially filled extents flushed at the end of     * 
* Load                                                         * 
* Phase was huge, increasing the probability of encountering   * 
* it.                                                          * 
**************************************************************** 
* RECOMMENDATION:                                              * 
* Upgrade to DB2 LUW version 9.1 fixpack 9                     * 
****************************************************************
Local Fix:
available fix packs:
DB2 Version 9.1 Fix Pack 9  for Linux, UNIX and Windows
DB2 Version 9.1 Fix Pack 10  for Linux, UNIX and Windows
DB2 Version 9.1 Fix Pack 11  for Linux, UNIX and Windows
DB2 Version 9.1 Fix Pack 12  for Linux, UNIX and Windows

Solution
This APAR is fixed in DB2 LUW version 9.1 fixpack 9
Workaround
not known / see Local fix
Timestamps
Date  - problem reported    :
Date  - problem closed      :
Date  - last modified       :
19.10.2009
13.05.2010
13.05.2010
Problem solved at the following versions (IBM BugInfos)
9.1.FP9
Problem solved according to the fixlist(s) of the following version(s)
9.1.0.9 FixList
This site uses cookies to make it easier for us to provide you with our services. By using our site you agree to the use of cookies.