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 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 FixList