DB2 - Problembeschreibung
Problem IT03888 | Status: Geschlossen |
RTS COLLECTING TABLE CARDINALITY AS 0 AFTER TRUNCATE AND POPULATE TABLE. | |
Produkt: | |
DB2 FOR LUW / DB2FORLUW / A10 - DB2 | |
Problembeschreibung: | |
RTS might not trigger synchronous statistics collection after the table is truncated and re-populated with large amount of data. This scenario can occur in the following situation. -truncate table T1 - fire the select statement -synchronous statistics collection got triggered and collected table cardinality as 0 for T1 -re-populated the table T1 with large amount of data -jits daemon woke up and processed asynchronous write operation on table T1 -select statement is fired and statistics collection did not happen. We still have table cardinality as 0 even though the table is populated with large amount of data. The above scenario happens due to timing gap. In this fix we have tried to minimize the timing gap, by not resetting the UDI counter during asynchronous write operation. | |
Problem-Zusammenfassung: | |
**************************************************************** * USERS AFFECTED: * * ALL * **************************************************************** * PROBLEM DESCRIPTION: * * See Error Description * **************************************************************** * RECOMMENDATION: * * Upgrade to DB2 10.1 FP 5 * **************************************************************** | |
Local-Fix: | |
This problem is more likely to be observed for tables which grow and shrink significantly and frequently, for example, tables which are truncated and then re-populated. Several workarounds are available in this situation: - Alter the table to have the VOLATILE attribute. This informs the query optimizer to take into consideration that the cardinality of the table can vary significantly at run time, from empty to large, whereby certain access methods will be preferred. - Change the job to include performing a runstats after re-populating the table. - Perform a one-time runstats against the table when it contains data that is representative of its daily re-populated state, and exclude the table from automatic statistics maintenance. | |
Lösung | |
Upgrade to DB2 10.1 FP 5 | |
Workaround | |
keiner bekannt / siehe Local-Fix | |
Weitere Daten | |
Datum - Problem gemeldet : Datum - Problem geschlossen : Datum - der letzten Änderung: | 20.08.2014 27.08.2015 27.08.2015 |
Problem behoben ab folgender Versionen (IBM BugInfos) | |
Problem behoben lt. FixList in der Version | |
10.1.0.5 |
![]() |