DB2 - Problembeschreibung
Problem IC63845 | Status: Geschlossen |
BAD PAGE DETECTED IN SQLB_VERIFY_PAGE WHILE EXEUCTING LOAD AGAINST A RANGE PARTITIONED TABLE | |
Produkt: | |
DB2 FOR LUW / DB2FORLUW / 910 - 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 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: | |
verfügbare FixPacks: | |
DB2 Version 9.1 Fix Pack 9 for Linux, UNIX and Windows | |
Lösung | |
This APAR is fixed in DB2 LUW version 9.1 fixpack 9 | |
Workaround | |
keiner bekannt / siehe Local-Fix | |
Weitere Daten | |
Datum - Problem gemeldet : Datum - Problem geschlossen : Datum - der letzten Änderung: | 19.10.2009 13.05.2010 13.05.2010 |
Problem behoben ab folgender Versionen (IBM BugInfos) | |
9.1.FP9 | |
Problem behoben lt. FixList in der Version | |
9.1.0.9 |