Materialized Query Tables

29.7 Materialized Query Tables

Materialized views are supported in DB2 in Linux, Unix, and Windows as well as on the z/ OS platforms. A materialized view can be any general view definition on one or more tables or views. A materialized view is useful since it maintains

a persistent copy of the view data to enable faster query processing. In DB2 a materialized view is called a materialized query table ( MQT ). MQT s are specified by using the create table statement as shown by the example in Figure 29.15.

In DB2 , MQT s can reference other MQT s to create a tree or forest of dependent views. These MQT s are highly scalable as they can be partitioned in an MPP environment and can have MDC clustering keys. MQT s are most valuable if the database engine can route queries to them seamlessly and also if the database engine can maintain them efficiently whenever possible. DB2 provides both of these features.

29.7.1 Query Routing to MQTs

The query-compiler infrastructure in DB2 is ideally suited to leverage the full power of MQT s. The internal QGM model allows the compiler to match the input query against the available MQT definitions and choose appropriate MQT s for consideration. After matching, the compiler considers several options for opti- mization. They include the base query as well as suitable MQT reroute versions. The optimizer loops through these options before choosing the optimal version for execution. The entire flow of the reroute and optimization is shown in Fig- ure 29.16.

29.7.2 Maintenance of MQTs

MQT s are useful only if the database engine provides efficient techniques for maintenance. There are two dimensions to maintenance: time and cost. In the time dimension, the two choices are immediate or deferred. DB2 supports both these choices. If one selects immediate, then internal triggers are created and compiled

29.7 Materialized Query Tables 1213

SQL query

Query semantics (validate reroute possibility)

MQT candidate match phase

MQT definitions

Query candidates

Optimization phase

Select best plan

Figure 29.16 MQT matching and optimization in DB2.

into the insert, update, or delete statements of the source objects to process the updates to the dependent MQT s. In the case of deferred maintenance, the updated tables are moved into an integrity mode and an explicit refresh statement must be issued to perform the maintenance. In the size dimension, the choices are incremental or full. Incremental maintenance implies that only the recently updated rows should be used for maintenance. Full maintenance implies that the entire MQT

be refreshed from its sources. The matrix in Figure 29.17 shows the two dimensions and the options that are most useful along these dimensions. For instance, immediate and full maintenance are not compatible unless the sources are extremely small. DB2 also allows for the MQT s to be maintained by user. In this case, the refresh of the MQT s is determined by users performing explicit processing using SQL or utilities.

The following commands provide one simple example of performing deferred maintenance for the emp dept materialized view after a load operation to one of its sources.

Full Immediate

Choices

Incremental

Usually no Deferred

Figure 29.17 Options for MQT maintenance in DB2.

1214 Chapter 29 IBM DB2 Universal Database

load from newdata.txt of type del insert into employee ;

refresh table emp dept