DB2 - Problembeschreibung
Problem IC77270 | Status: Geschlossen |
DATABASE MAY CRASH AFTER A MEMORY CORRUPTION FOR QUERIES THAT CONTAIN DECFLOAT(34) COLUMNS WITHIN A TABLEQUEUE. | |
Produkt: | |
DB2 FOR LUW / DB2FORLUW / 970 - DB2 | |
Problembeschreibung: | |
This APAR fixes a memory corruption that is caused by a memory alignment problem in the internal structures that deal with the tablequeues logic. A tablequeue is the access plan functionality that allows for the sending of row data in between subsections of the plan. As such, you can only get an access plan that features a tablequeue for an instance configured with the data partitioning facility (DPF), OR, if the instance is configured for intra-partition parallelism (the dbm cfg setting of INTRA_PARALLEL is turned on). Otherwise, this problem cannot be encountered. In addition, the conditions to potentially hit the problem are: - there is a tablequeue in the access plan that contains DECFLOAT(34) columns in the tablequeue row. - a memory allocation during the query initialization happens by chance to have a certain alignment. There is no way to control this alignment, however it's noted that it's somewhat rare to achieve the alignment necessary to result in this problem. - the problem is more likely to occur for, but not limited to, sorted/merging tablequeues The APAR will fix the alignment of the allocation and remove the potential to encounter the memory corruption. Since this defect is about a memory corruption, it means that the end symptom may not be clearly defined since it depends on what things get overwritten by the corruption. Typically for this defect, we have seen crashes when an agent has read a row from the tablequeue, but the row data does not make sense so the subsequent handling of the row fails. An example stack that we have seen for this is the following, where an insert failed because it read the bad data from the corrupted tablequeue, but there is likely other potential traps that could happen: sqldValidateData + 0xAD0 sqldFastFormatFixedVar + 0x540 sqldFastFormat + 0x5C sqldRowInsert + 0xC14 sqlrinsr + 0x108 | |
Problem-Zusammenfassung: | |
**************************************************************** * USERS AFFECTED: * * - there is a tablequeue in the access plan that contains * * DECFLOAT(34) columns in the tablequeue row. * * - a memory allocation during the query initialization * * happens by * * chance to have a certain alignment. There is no way to * * control * * this alignment, however it's noted that it's somewhat rare * * to * * achieve the alignment necessary to result in this problem. * * - the problem is more likely to occur for, but not limited * * to, * * sorted/merging tablequeues * **************************************************************** * PROBLEM DESCRIPTION: * * See error description * **************************************************************** * RECOMMENDATION: * * Upgrade to DB2 9.7 Fix Pack 5 * **************************************************************** | |
Local-Fix: | |
Lösung | |
Problem fixed in v97fp5 | |
Workaround | |
keiner bekannt / siehe Local-Fix | |
Weitere Daten | |
Datum - Problem gemeldet : Datum - Problem geschlossen : Datum - der letzten Änderung: | 30.06.2011 16.12.2011 16.12.2011 |
Problem behoben ab folgender Versionen (IBM BugInfos) | |
9.7.FP5 | |
Problem behoben lt. FixList in der Version |