DB2 FOR LUW / DB2FORLUW / A50 - DB2

The automatics statistics collection facility uses UDI 
(update/delete/insert) activity information when deciding 
whether to perform runstats against a table.  Under rare 
conditions, the in-memory UDI data for a table might be lost, 
which in turn might lead to a failure to collect new statistics 
for the table as the automatics statistics collection facility 
does not think the table has had significant UDI activity, which 
in turn might lead to the query optimizer choosing a poor access 
plan. 
 
When the problem occurs, the statistics logs might show that a 
SQL1224 error, suggested an automatic runstats was forced. 
 
The fix for APAR IC91562 is a prerequisite when applying the fix 
for IC91713.

**************************************************************** 
* USERS AFFECTED:                                              * 
* All users                                                    * 
**************************************************************** 
* PROBLEM DESCRIPTION:                                         * 
* See Error Description                                        * 
**************************************************************** 
* RECOMMENDATION:                                              * 
* Upgrade to DB2 v10.5 FP3 or latest release.                  * 
****************************************************************

Workaround: 
 
While this problem is generic in nature, it 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.  Consider an example of a daily job where a table 
is populated, queries are executed, and then the table is 
truncated.  Several workarounds are available in this situation: 
- Change the job so that the table truncation step starts the 
job.  This reduces the probability that the auto_runstats daemon 
might perform runstats on the table when it is empty, which 
reduces the probability that the optimizer might think the table 
is empty when compiling the queries, should the in-memory UDI 
information be lost leading the automatics statistics collection 
facility to not take action. 
- 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. 
 
In general situations where a poor access plan is identified and 
a better access plan is known, direct the optimizer to the 
better access plan via an optimization guideline.

DB2 Version 10.5 Fix Pack 3 for Linux, UNIX, and Windows
 DB2 Version 10.5 Fix Pack 3a for Linux, UNIX, and Windows
 DB2 Cancun Release 10.5.0.4 (also known as Fix Pack 4) for Linux, UNIX, and Windows
 DB2 Version 10.5 Fix Pack 9 for Linux, UNIX, and Windows
 

not known / see Local fix

Date  - problem reported    :
Date  - problem closed      :
Date  - last modified       :

27.08.2013
07.08.2014
07.08.2014