Allow more granular control over what SQL will result in Statistics Profiles updates

Unnecessary statistics can increase RUNSTATS collection elapsed and CPU time, sometimes exponentially, and impact BIND/PREPARE performance because the optimizer must read in all available statistics to determine what is and is not useful for each query.

Multi-column frequencies are only exploited by the optimizer for equal predicates containing literal values. These extra statistics would not be useful in systems with static SQL using host variables and dynamic SQL using parameter markers. Ad-hoc SQL that may contain literals that is infrequently submitted or submitted once results in Db2 automatically updating the statistics profiles with unnecessary RUNSTATS options.

We have observed unnecessary RUNSTATS options in the statistics profiles that do not support production SQL transactions. These additional options are directly attributable to ad-hoc SQL that was executed for one-time data analysis or other non-production functionality purposes. Ad-hoc SQL often has literal values while production transaction SQL will use a combination of literals, host variables or parameter markers. We need the ability to exclude the ad-hoc SQL from the statistics feedback and statistics profiles update processing. We need the ability to only include the production transaction SQL.

Within a given production Db2 subsystem there can be both static Db2 packages and dynamic SQL transactions supporting application functionality. The STATFDBK_SCOPE subsystem parameter does not have the required granularity to exclude ad-hoc SQL.

The STATFDBK_SCOPE (ALL, DYNAMIC, NONE, or STATIC) and STATFDBK_PROFILE (YES or NO) Db2 subsystem parameters control whether or not SQL statements are included in the SYSIBM.SYSSTATFEEDBACK catalog table and whether or not the statistics recommendations result in statistics profiles modifications. More granular control is necessary to either only include SQL executed by specific users or exclude SQL executed by specific users. For example, only include SQL executed by specific RACF users or RACF group ids. The enhancement should allow exclusions as well. If possible, the enhancement should allow wildcard characters.