DB2 UDB for z/OS Version 8 Performance Topics - IBM Redbooks

The most important factor in the return on investment on MQTs remains the frequency of
utilization, and, therefore, a balance of how specialized the MQT is and how well it performs
versus the range of applicability.
3.2.6 Recommendations
MQTs allow more flexibility for the physical data base design of tables at the detailed level
(sometimes known as atomic level) in a corporate data warehouse. The base tables can be
more normalized, closer to the conceptual model, and the performance issues of long running
queries involving joins, summarizations, and subqueries can be resolved when materialized
as MQTs.
Plan MQTs for the top consuming queries, not for all queries. Use MQTs to aggregate results
based on the most used predicates joining large tables and allow the DB2 optimizer to use
regrouping, predicate matching and expression derivation.
Multi-dimensional applications can gain benefits by using MQTs, when queries have
opportunities for regrouping.
If you can identify these cases, the same MQT can be reused in many different queries. A
good case is when a new table in the DB2 work file as a result of join is scanned a large
number of times in a nested loop join: MQTs can be indexed.
The use of MQTs can potentially provide huge savings in a data warehouse environment. It is
good for queries, but not for OLTP due to the extra cost for BIND.
For large MQTs, remember to:
► Use segmented table spaces because of the almost instantaneous mass delete in
REFRESH TABLE.
► Execute RUNSTATS after REFRESH for good access path selection; otherwise, DB2 uses
default or out-of-date statistics.
Keep the number of MQTs for a base table down to an acceptable number to avoid the extra
cost of BIND time due to the large number of MQTs eligible for query rewrite, as well as the
processing necessary for the maintenance of MQTs. For a simple query the measured
overhead is about 0.4 ms to examine each qualified MQT.
When creating a user-maintained materialized query table, initially disable query optimization.
Otherwise, DB2 might automatically rewrite queries to use the empty materialized query
table.
3.3 Star join processing enhancements
3.3.1 Star schema
In this section we describe how, in DB2 V8, the execution of star join is improved by:
► Access path enhancements
► Better estimates of the filtering effect of dimensions
► Use of sparse indexes in cache for materialized snowflakes
► Use of in-memory work files
The star schema data model is often used in data warehouses, data marts and OLAP. The
representation of a star schema is shown in Figure 3-15.
Chapter 3. SQL performance 53