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

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

Produkt:
DB2 FOR LUW / DB2FORLUW / 970 - DB2
Problembeschreibung:
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-Zusammenfassung:
**************************************************************** 
* USERS AFFECTED:                                              * 
* Users loading into a range partition table                   * 
**************************************************************** 
* 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        * 
* advertently 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.7 fp2                           * 
****************************************************************
Local-Fix:
verfügbare FixPacks:
DB2 Version 9.7 Fix Pack 2 for Linux, UNIX, and Windows
DB2 Version 9.7 Fix Pack 3 for Linux, UNIX, and Windows
DB2 Version 9.7 Fix Pack 3a for Linux, UNIX, and Windows
DB2 Version 9.7 Fix Pack 4 for Linux, UNIX, and Windows
DB2 Version 9.7 Fix Pack 5 for Linux, UNIX, and Windows
DB2 Version 9.7 Fix Pack 6 for Linux, UNIX, and Windows
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 9a for Linux, UNIX, and Windows
DB2 Version 9.7 Fix Pack 9 for Linux, UNIX, and Windows
DB2 Version 9.7 Fix Pack 10 for Linux, UNIX, and Windows

Lösung
This problem is first fixed in db2_v97fp2
Workaround
keiner bekannt / siehe Local-Fix
Weitere Daten
Datum - Problem gemeldet    :
Datum - Problem geschlossen :
Datum - der letzten Änderung:
17.11.2009
02.07.2010
02.07.2010
Problem behoben ab folgender Versionen (IBM BugInfos)
9.7.FP2
Problem behoben lt. FixList in der Version
9.7.0.2 FixList