Howdy!
In this final installment, I will be covering on how to ensure optimum model repository performance for IBM DB2.
[Update Statistics]
RUNSTATS command
Updates statistics in the system catalog about the characteristics of a table and/or associated indexes, or statistical views. These characteristics include number of records, number of pages, and average record length. The optimizer uses these statistics when determining access paths to the data.
- Collect statistics on the table only, on all columns without distribution statistics:
- Collect statistics on the table only, on columns empid and empname with distribution statistics:
- Collect statistics on the table only, on all columns with distribution statistics using a specified number of frequency limit for the table while picking the num_quantilesfrom the configuration setting:
- Collect statistics on the table only, on all columns with distribution statistics, and on column group JOB, WORKDEPT, and SEX:
- Collect statistics on a set of indexes:
- Collect basic statistics on all indexes only:
- Collect basic statistics on the table and all indexes using sampling for the detailed index statistics collection:
- Collect statistics on table, with distribution statistics on columns empid, empname and empdept and the two indexes Xempid and Xempname. Distribution statistics limits are set individually for empdept, while the other two columns use a common default:
- Collect statistics on all columns used in indexes and on all indexes:
- Collect statistics on all indexes and all columns without distribution except for one column. Consider T1 containing columns c1, c2, …., c8
- Collect statistics on table T1 for the individual columns c1 and c5 as well as on the column groups (c2, c3) and (c2, c4). Multicolumn cardinality is very useful to the query optimizer when it estimates filter factors for predicates on columns in which the data is correlated.
- Collect statistics on table T1 for the individual columns c1 and c2. For column c1 also collect the LIKE predicate statistics.
- Register a statistics profile to collect statistics on the table only, on all columns with distribution statistics using a specified number of frequency limit for the table while picking the num_quantiles from the configuration setting. The command also updates the statistics as specified.
- Register a statistics profile to collect statistics on the table only, on all columns with distribution statistics using a specified number of frequency limit for the table while picking the num_quantiles from the configuration setting. Statistics are not collected.
- Modify the previously registered statistics profile by changing the NUM_FREQVALUES value from 50 to 30. The command also updates the statistics as specified.
- Modify the previously registered statistics profile by changing the NUM_FREQVALUES value from 50 to 30. Statistics are not collected.
- Modify the previously registered statistics profile by adding column and column group (, ) options. The command also updates the statistics as specified.
- Modify the previously registered statistics profile by adding column and column group (, ) options. Statistics are not collected.
- Collect statistics on a table using the options recorded in the statistics profile for that table:
- Query the RUNSTATS command options corresponding to the previously registered statistics profile stored in the catalogs of the table:
- Collect statistics, including distribution statistics, on 30 percent of the rows:
- To control the sample set on which statistics will be collected and to be able to repeatedly use the same sample set, you can do so as follows: Issuing the same statement as above will result in the same set of statistics as long as the data has not changed in the interim.
- Collect index statistics as well as table statistics on 1.5 percent of the data pages. Only table data pages and not index pages are sampled. In this example 1.5 percent of table data pages are used for the collection of table statistics, while for index statistics all the index pages will be used:
- Collect statistics for a statistical view, on all columns, without distribution statistics:
- Collect statistics for a statistical view, with distribution statistics on the columns , and . Distribution statistics limits are set for the column, while the other columns use a common default:
- Collect statistics, including distribution statistics, on 10 percent of the rows using row level sampling:
- Collect statistics, including distribution statistics, on 2.5 percent of the rows using data page level sampling. Additionally, specify the repeated use of the same sample set. For this command to succeed, the query must be such that the DB2 database system can successfully push data page sampling down to one or more tables. Otherwise, an error (SQL 20288N) is issued.
- Register a statistics profile to collect statistics on the view and on all columns with distribution statistics as specified:
- Modify the previously registered statistics profile. This command also updates the statistics as specified:
[Source: IBM DB2 Documentation]
[Perform Table Re-Orgs and Index Re-Orgs]
Before you perform a Table Re-Org, make sure you run the REORGCHK command.
REORG TABLE commands and REORG INDEXES ALL commands can be issued on a data partitioned table to concurrently reorganize different data partitions or partitioned indexes on a partition. When concurrently reorganizing data partitions or the partitioned indexes on a partition, users can access the unaffected partitions but cannot access the affected partitions. All the following criteria must be met to issue REORG commands that operate concurrently on the same table:
- Each REORG command must specify a different partition with the ON DATA PARTITION clause.
- Each REORG command must use the ALLOW NO ACCESS mode to restrict access to the data partitions.
- The partitioned table must have only partitioned indexes if issuing REORG TABLE commands. No non-partitioned indexes (except system-generated XML path indexes) can be defined on the table. [Source: IBM Knowledge base]
Again as always, ensure these are run during non-production hours and this will ensure a smooth running of your ER/Studio Model Repository IBM DB2 Database!
Stay tuned for more posts on our products!