materialized view的fast和日誌分析和一則案例

物化檢視多使用者資料倉儲，資料複製等環境，自己接觸的還是主要是用於簡單的查詢，讓其利用所謂的空間換取時間，提高系統的效能。重新整理機制和查詢重寫是物化檢視最重要的功能。

下面結合自己碰到的一則物化檢視的ora處理來簡要說一下物化檢視和日誌和fast重新整理機制。

mview_tab01表是主表，下面的mv01是mview_tab01的物化檢視。先來看看下面的物化檢視日誌的表的結構。

SQL> alter table mview_tab01 add primary key(id);

Table altered

SQL> create materialized view log on mview_tab01;

Materialized view log created

SQL> create materialized view mv01

2 build immediate

3 refresh fast

4 start with sysdate

5 next sysdate+5/1440

6 enable query rewrite

7 as

8 select * from mview_tab01;

Materialized view created

SQL> insert into mview_tab01 values(5,'ORCL');

1 row inserted

SQL> commit;

Commit complete

SQL> col change_vector$$ for a10

SQL> col change_vector$$ for a10

SQL> select * from mlog$_mview_tab01;

ID SNAPTIME$$ DMLTYPE$$ OLD_NEW$$ CHANGE_VEC XID$$

---------- ----------- --------- --------- ---------- ----------

5 4000/1/1 I N FE 2815995307

SQL> insert into mview_tab01 values(8,'ORACLE');

1 row inserted

SQL> select * from mlog$_mview_tab01;

ID SNAPTIME$$ DMLTYPE$$ OLD_NEW$$ CHANGE_VEC XID$$

---------- ----------- --------- --------- ---------- ----------

5 4000/1/1 I N FE 2815995307

8 4000/1/1 I N FE 1.97036349

SQL> commit;

Commit complete

Dbms_mview.refresh重新整理一下物化檢視，然後再檢視物化檢視的日誌。

SQL> select * from mlog$_mview_tab01;

ID SNAPTIME$$ DMLTYPE$$ OLD_NEW$$ CHANGE_VEC XID$$

---------- ----------- --------- --------- ---------- ----------

物化檢視已經重新整理修改，且物化檢視的日誌也已經再次清空。

SQL> delete from mview_tab01 where id=8;

1 row deleted

SQL> select * from mlog$_mview_tab01;

ID SNAPTIME$$ DMLTYPE$$ OLD_NEW$$ CHANGE_VEC XID$$

---------- ----------- --------- --------- ---------- ----------

8 4000/1/1 D O 00 1.12602016

SQL> execute dbms_mview.refresh('MV01');

PL/SQL procedure successfully completed

SQL> select * from mlog$_mview_tab01;

ID SNAPTIME$$ DMLTYPE$$ OLD_NEW$$ CHANGE_VEC XID$$

---------- ----------- --------- --------- ---------- ----------

這裡注意一下mlog$_mview_tab01檢視的column的含義

SQL> desc mlog$_mview_tab01;

Name Type Nullable Default Comments

--------------- ----------- -------- ------- --------

ID NUMBER Y

SNAPTIME$$ DATE Y

DMLTYPE$$ VARCHAR2(1) Y

OLD_NEW$$ VARCHAR2(1) Y

CHANGE_VECTOR$$ RAW(255) Y

XID$$ NUMBER Y

上述是主鍵物化檢視的日誌，id主鍵，snaptime$$重新整理時間，dmltype$$表示dml操作型別，上述的I表示insert，d表示delete，change_vector$$修改向量，用於表示修改的欄位值是哪些，不過內部演算法比較複雜暫時不做深究。

如果是rowid和object的物化檢視日誌的檢視有少許不同，這裡就不列舉。

物化檢視之所以能fast refresh是利用檢視的日誌來傳遞資訊到物化檢視中更新，refresh前物化檢視會先根據基表是否發生變化，如果不發生變化，即使物化檢視日誌有記錄資訊，物化檢視也不會重新整理資料。

先讀取基表是否發生變化是refresh的第一步，然後才會傳遞日誌記錄到物化檢視重新整理資料。

今天碰到一則materialized view fast的案例，物化檢視無法重新整理，手動重新整理也出現下列錯誤。

SQL> execute dbms_mview.refresh('MV_ARTICLE');

BEGIN dbms_mview.refresh('MV_ARTICLE'); END;

*

ERROR at line 1:

ORA-12034: materialized view log on "DESKTOP"."ARTICLE" younger than last refresh

ORA-06512: at "SYS.DBMS_SNAPSHOT", line 2255

ORA-06512: at "SYS.DBMS_SNAPSHOT", line 2461

ORA-06512: at "SYS.DBMS_SNAPSHOT", line 2430

ORA-06512: at line 1

[oracle@server119 ~]$ oerr ora 12034

12034, 0000, "materialized view log on "%s"."%s" younger than last refresh"

// *Cause: The materialized view log was younger than the last refresh.

// *Action: A complete refresh is required before the next fast refresh.

根據物化檢視的重新整理機制會重新整理snaptime$$大於物化檢視上次refresh時間的記錄（上次refresh的時間可以檢視user_mviews等檢視），重新整理完成後將修改資料字典中last_refresh_date重新整理時間.下次refresh就會根據snaptime$$l來refresh上次的重新整理時間後的資料，也就是記錄到mlog$_mview_tab01的日誌記錄資訊，並清除已經refresh的snaptime$$的資訊記錄。

（不過上述的ora錯誤出現時，mlog檢視中會出現早於上次refresh的snaptime記錄，這個也是錯誤的進一步表象）

根據提示materialized view log比上次的article重新整理還早，那麼再次重新整理時要利用view log的，由於日誌snaptime$$早於上次refresh導致無法利用log重新整理，此種情況可以重建物化檢視或者完全重新整理來解決，多發生於對物化檢視和基表，物化檢視日誌做過相應的ddl操作引起。

[@more@]