轉自:http://blog.csdn.net/joshua_peng1985/article/details/6213593 介紹
物化視圖是一種特殊的物理表,“物化”(Materialized)視圖是相對普通視圖而言的。普通視圖是虛擬表,應用的局限性大,任何對視圖的查詢,Oracle都實際上轉換為視圖SQL語句的查詢。這樣對整體查詢效能的提高,並沒有實質上的好處。
1、物化視圖的類型:ON DEMAND、ON COMMIT
二者的區別在於重新整理方法的不同,ON DEMAND顧名思義,僅在該物化視圖“需要”被重新整理了,才進行重新整理(REFRESH),即更新物化視圖,以保證和基表資料的一致性;而ON COMMIT是說,一旦基表有了COMMIT,即事務提交,則立刻重新整理,立刻更新物化視圖,使得資料和基表一致。
2、ON DEMAND物化視圖
物化視圖的建立本身是很複雜和需要最佳化參數設定的,特別是針對大型生產資料庫系統而言。但Oracle允許以這種最簡單的,類似於普通視圖的方式來做,所以不可避免的會涉及到預設值問題。也就是說Oracle給物化視圖的重要定義參數的預設值處理是我們需要特別注意的。
物化視圖的特點:
(1) 物化視圖在某種意義上說就是一個物理表(而且不僅僅是一個物理表),這通過其可以被user_tables查詢出來,而得到佐證;
(2) 物化視圖也是一種段(segment),所以其有自己的實體儲存體屬性;
(3) 物化視圖會佔用資料庫磁碟空間,這點從user_segment的查詢結果,可以得到佐證;
建立語句:create materialized view mv_name as select * from table_name
預設情況下,如果沒指定重新整理方法和重新整理模式,則Oracle預設為FORCE和DEMAND。
3、物化視圖的資料怎麼隨著基表而更新。
Oracle提供了兩種方式,手工重新整理和自動重新整理,預設為手工重新整理。也就是說,通過我們手工的執行某個Oracle提供的系統級預存程序或包,來保證物化視圖與基表資料一致性。這是最基本的重新整理辦法了。自動重新整理,其實也就是Oracle會建立一個job,通過這個job來調用相同的預存程序或包,加以實現。
4、ON DEMAND物化視圖的特性及其和ON COMMIT物化視圖的區別
前者不重新整理(手工或自動)就不更新物化視圖,而後者不重新整理也會更新物化視圖,——只要基表發生了COMMIT。
建立定時重新整理的物化視圖:
create materialized view mv_name refresh force on demand start with sysdatenext sysdate+1 (指定物化視圖每天重新整理一次)
上述建立的物化視圖每天重新整理,但是沒有指定重新整理時間,如果要指定重新整理時間(比如每天晚上10:00定時重新整理一次):
create materialized view mv_name refresh force on demand start with sysdate next to_date( concat( to_char( sysdate+1,'dd-mm-yyyy'),' 22:00:00'),'dd-mm-yyyy hh24:mi:ss')
5、ON COMMIT物化視圖
ON COMMIT物化視圖的建立,和上面建立ON DEMAND的物化視圖區別不大。因為ON DEMAND是預設的,所以ON COMMIT物化視圖,需要再增加個參數即可。
需要注意的是,無法在定義時僅指定ON COMMIT,還得附帶個參數才行。
建立ON COMMIT物化視圖:
create materialized view mv_name refresh force on commit as select * from table_name
備忘:實際建立過程中,基表需要有主鍵約束,否則會報錯(ORA-12014)
6、物化視圖的重新整理
重新整理(Refresh):指當基表發生了DML操作後,物化視圖何時採用哪種方式和基表進行同步。重新整理的模式有兩種:ON DEMAND和ON COMMIT。(如上所述)
重新整理的方法有四種:FAST、COMPLETE、FORCE和NEVER。
FAST重新整理採用增量重新整理,只重新整理自上次重新整理以後進行的修改。COMPLETE重新整理對整個物化視圖進行完全的重新整理。如果選擇FORCE方式,則Oracle在重新整理時會去判斷是否可以進行快速重新整理,如果可以則採用FAST方式,否則採用COMPLETE的方式。NEVER指物化視圖不進行任何重新整理。
對於已經建立好的物化視圖,可以修改其重新整理方式,比如把物化視圖mv_name的重新整理方式修改為每天晚上10點重新整理一次:
alter materialized view mv_name refresh force on demand start with sysdate next to_date(concat(to_char(sysdate+1,'dd-mm-yyyy'),' 22:00:00'),'dd-mm-yyyy hh24:mi:ss')
7、物化視圖具有表一樣的特徵,所以可以像對錶一樣,我們可以為它建立索引,建立方法和對錶一樣。
8、物化視圖的刪除:
雖然物化視圖是和表一起管理的,但是在經常使用的PLSQL工具中,並不能用刪除表的方式來刪除(在表上右鍵選擇‘drop’並不能刪除物化視圖),可以使用語句來實現:
drop materialized view mv_name
其他參考
普通視圖和物化視圖的區別
普通視圖和物化視圖根本就不是一個東西,說區別都是硬拼到一起的,首先明白基本概念,普通視圖是不儲存任何資料的,他只有定義,在查詢中是轉換為對應的定義SQL去查詢,而物化視圖是將資料轉換為一個表,實際儲存著資料,這樣查詢資料,就不用關聯一大堆表,如果表很大的話,會在暫存資料表空間內做大量的操作。
普通視圖的三個特徵:
1、是簡化設計,清晰編碼的東西,他並不是提高效能的,他的存在只會降低效能(如一個視圖7個表關聯,另一個視圖8個表,程式員不知道,覺得很方便,把兩個視圖關聯再做一個視圖,那就慘了),他的存在未了在設計上的方便性
2、其次,是安全,在授權給其他使用者或者查看角度,多個表關聯只允許查看,不允許修改,單表也可以同WITH READ ONLY來控制,當然有些項目基於視圖做物件導向的開發,即在視圖上去做INSTAND OF觸發器,就我個人而言是不站同的,雖然開發上方便,但是未必是好事。
3、從不同的角度看不同的維度,視圖可以劃分維度和許可權,並使多個維度綜合,也就是你要什麼就可以從不同的角度看,而表是一個實體的而已,一般維度較少(如:人員表和身份表關聯,從人員表可以查看人員的維度統計,從身份看,可以看不同種類的身份有那些人或者多少人),其次另一個如系統檢視表USER_TABLE、TAB、USER_OBJECTS這些視圖,不同的使用者下看到的肯定是不一樣的,看的是自己的東西。
物化視圖呢,用於OLAP系統中,當然部分OLTP系統的小部分功能未了提高效能會借鑒一點點,因為表關聯的開銷很大,所以在開發中很多人就像把這個代價交給定期轉存來完成,ORACLE當然也提供了這個功能,就是將視圖(或者一個大SQL)的資訊轉換為物理資料存放區,然後提供不同的策略:定時刷還是及時刷、增量刷還是全域刷等等可以根據實際情況進行選擇,總之你差的是表,不是視圖。 關於在重新整理和索引上的區別
他們兩個沒有聯絡吧,重新整理我不清楚你是否指的是物化視圖的重新整理,因為重新整理的概念很泛,你說到這裡我就理解為物化視圖的重新整理了,上面也已經說了,這是一種策略和方法,其實它是通過對視圖關聯表上建立相應的LOG,根據日誌資訊的SQL同步到物化視圖中的,一般來說:定時的一般是全域刷,及時的一般是局部刷。
而索引這個說起來就多了,可以說索引專門是一門課程,大概點來說,索引一般有普通索引、位元影像索引、唯一性索引(還有全文索引啥的,一般不用),其實仔細研究會發現無論是那一種索引都是B+樹為基礎,並起存放方式和表一樣,是以段為單位,只是內部有樹關係而已。
1、普通索引是根據B+樹找到第一個(索引時有序的),然後以當前為基準,向後順序找到不合格健值為止。
2、位元影像是在葉子節點上根據位元影像種類對葉子節點的值進行01編碼存放(如該欄位有1、2、3三種值,就會在葉子節點上有三個位元影像,每個位元影像根據健值和ROWID順序存放是否為1、是否為2、是否為3,所以在RBO下統計很快,CBO下一般會認為是普通索引)。
3、也是按照B+樹找,只是找到就不再做任何操作,因為是唯一的。
因為B+尋找是一個類似表的查詢,而且擷取到ROWID後還是要回表查詢的,所以這個過程的開銷要和全表掃描計算那個結果更加快,ORACLE才會選擇是走索引還是走全表掃描,當然對於CBO和RBO選擇的方式不一樣,具體又是很多,CBO要依賴於表的統計資訊,RBO是依賴於嘗試。
關於B+樹的相關內容,可以參考下面這篇文章:
從B 樹、B+ 型樹狀結構、B* 樹談到R 樹