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

3.2.1 Creating MQTs
MQTs compared to views
► MQTs occupy storage space
► MQTs are not usually referenced in a user query, but typically referenced via query rewrite
by DB2.
MQTs compared to indexes
► MQTs can be associated with multiple tables. An index can be created for one table only.
► Exploitation of MQTs and indexes is transparent to the applications.
We use the extended CREATE TABLE SQL statement to define an MQT and we:
► Specify a fullselect associated with a table
► Specify the mechanisms that are used to refresh the MQT
► Enable/disable an MQT for automatic query rewrite
The privilege set needed to define the MQT must include at least one of the following:
► The CREATETAB privilege for the database, implicitly or explicitly specified by the IN
clause
► DBADM, DBCTRL, or DBMAINT authority for the database in which the table is being
created
► SYSADM or SYSCTRL authority
See Example 3-3 for the DDL of a materialized query table.
Example 3-3 Define a table as MQT
CREATE TABLE TRANSCNT (ACCTID, LOCID, YEAR, CNT) AS (
SELECT ACCTID, LOCID, YEAR, COUNT(*)
FROM TRANS
GROUP BY ACCTID, LOCID, YEAR )
DATA INITIALLY DEFERRED
REFRESH DEFERRED
MAINTAINED BY SYSTEM
ENABLE QUERY OPTIMIZATION;
Options creating MQTs
The options are:
► DATA INITIALLY DEFERRED
– The MQTs are not populated at creation
– Use REFRESH TABLE to populate a system-maintained MQT
– Use the INSERT statement to insert data into a user-maintained MQT or use LOAD
► REFRESH DEFERRED
– Data in the MQT is not refreshed when its base tables are updated
– Can be refreshed any time using the REFRESH TABLE statement
► MAINTAINED BY SYSTEM/USER
► ENABLE /DISABLE QUERY OPTIMIZATION
Referential constraints between base tables are also an important factor in determining
whether a materialized query table can be used for a query.
40 DB2 UDB for z/OS Version 8 Performance Topics