Database Reference
In-Depth Information
Figure 15-3.
After modifying the base tables, the materialized view has to be refreshed
Now that I've introduced the basic concepts, let me describe, in more detail, which parameters can be specified
during the creation of materialized views, and how query rewrite and refreshes work.
Parameters
As you saw in the previous section, you can create a materialized view without specifying parameters. However, you
can fully customize its creation:
•
You can specify physical properties such as partitioning, compression, tablespace, and storage
parameters for the container table. In this regard, the container table is handled like any other
heap table. Owing to this, you can apply the techniques discussed in Chapter 13 to further
optimize data access.
•
When the materialized view is created, the query is executed, and the result set is inserted
into the container table. This is because the
build immediate
parameter is used by default.
Two additional possibilities exist: first, to defer the insertion of the rows to the first refresh by
specifying the
build deferred
parameter, and second, to reuse an already existing table as
the container table by specifying the
on prebuilt table
parameter.
enable query rewrite
parameter. Enabling query rewrite is supported in Enterprise Edition only.
•
By default, query rewrite is disabled. To enable it, you must specify the
•
To improve the performance of fast refreshes (described later in this chapter), an index
is created on the container table by default. To suppress the creation of this index, you
can specify the
using no index
parameter. This is useful, for example, for avoiding index
maintenance overhead, which might be far from negligible, if you never want to perform fast
refreshes.
