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

Before the introduction of MQTs, DB2 had to struggle through long data warehouse queries.
And the DBA had to pre-elaborate complex SELECTs with lots of UNIONs and JOINS in
order to create intermediate tables to be used by application people.
Figure 3-60 shows the graph for the query in Figure 3-13 (no MQT).
Figure 3-60 Explain without using an MQT table by Visual Explain
DB2 accesses an MQT the same way it accesses a base table with one exception: DB2
cannot use a direct fetch to access a materialized query table.
When underlying data changes, DB2 does not automatically refresh MQTs. To keep the MQT
data current, you must issue a REFRESH TABLE statement if the table is system-maintained,
or, if the materialized query table is user-maintained, you must issue INSERT, UPDATE, and
DELETE statements as needed. To control the use of MQTs, use the CURRENT REFRESH
AGE and CURRENT MAINTAINED TABLE TYPES FOR OPTIMIZATION special registers.
An MQT node is labeled with the name of the MQT and is, by default, displayed as an
upside-down trapezoid. The table's correlation name, creator name, or cardinality can also be
displayed on the label. If the RUNSTATS utility has not collected statistics for the table, the
node is outlined in red. If the optimizer uses the default value for the cardinality, the cardinality
is marked as the default.
On Figure 3-61 you can see the EXPLAIN graph generated by the VE of a query using the
MQT table with the name MATPROC ID = 14 and Cardinality = 6.
124 DB2 UDB for z/OS Version 8 Performance Topics