Question

CREATE TABLE TEST_DATE(COL1 VARCHAR2(20),COL2 NUMBER,COL3_DATE DATE,COL4_DATE DATE)
/   

create materialized view TEST_SYS
REFRESH FORCE ON DEMAND
ENABLE QUERY REWRITE  --- ????
AS
SELECT COL1,COL2
FROM    TEST_date
WHERE TRUNC(SYSDATE) BETWEEN TRUNC(COL3_DATE) AND TRUNC(COL4_DATE)
/

If Enable Query Rewrite option is disabled, MView is getting created for the above query then what is the purpose of having ENABLE QUERY REWRITE clause while creating materialized view, can we remove it and create it, and do we have to compromise on the performance of the MView if we have to comment Enable Query Rewrite.

Please explain me the use of enable query rewrite option in detail.

Answer 1

Query rewrite allows Oracle to rewrite a query against the base table (in this case TEST_DATE) to use the materialized view (in this case TEST_SYS) transparently. That is highly useful when your materialized view is pre-aggregating data, for example. If I have a transactions table and a materialized view

CREATE MATERIALIZED VIEW mv_transaction_daily
  REFRESH FORCE ON DEMAND
  ENABLE QUERY REWRITE
AS
SELECT store_id,
       transaction_day,
       SUM(transaction_amount) total_transaction_amount
  FROM transactions
 GROUP BY store_id, transaction_day

then Oracle could transform a query like

SELECT store_id,
       transaction_day,
       SUM(transaction_amount) total_transaction_amount
  FROM transactions
 GROUP BY store_id, transaction_day

to use the materialized view rather than hitting the base table. And if you have appropriate dimension objects created, you could have a query like

SELECT store_id,
       trunc(transaction_day,'MM'),
       SUM(transaction_amount) monthly_transaction_amount
  FROM transactions
 GROUP BY store_id, trunc(transaction_day,'MM')

that could also be rewritten to use the materialized view rather than the base table.

If query rewrite is not enabled, you would only see a performance benefit from using the materialized view if you explicitly queried the materialized view rather than querying the base table. That generally requires more development effort and limits the ability of the DBAs to tune the application in the future by fine-tuning materialized views.

In your case, the presence of SYSDATE in your WHERE clause is going to prevent query rewrite because Oracle wouldn’t be able to figure out that a query against TEST_DATE would actually be able to use the materialized view. For all Oracle knows, data in the materialized view that satisfied the condition when the materialized view was refreshed no longer satisfies the condition and data that didn’t make it into the materialized view now satisfies the condition simply because the SYSDATE has changed.