在這種情況下使用物化視圖還是普通視圖？

基於一些研究，似乎AGGREGATION在物化視圖中不能使用FAST FRESH？在這種情況下使用物化視圖還是普通視圖？

我發現一塊oracle document指出Complex Materialized View無法快速刷新。

In some cases, an aggregate function, although it is possible to have an aggregate 
function in the defining query and still have a simple materialized view. 
For example, the following statement creates a complex materialized view: 

CREATE MATERIALIZED VIEW hr.average_sal AS 
SELECT AVG(salary) "Average" FROM [email protected];

物化視圖我創建包含多次的結果加入SUM()聚合（6 6聯接應返回一些8 thousand行）。該視圖應該每20秒刷新一次。這裏是腳本

CREATE MATERIALIZED VIEW V_MVIEW$BASEVIEW 
BUILD IMMEDIATE 
REFRESH FAST START WITH (sysdate) NEXT (sysdate+1*20/(60*60*24)) WITH PRIMARY KEY 
AS 
    select 
     cb.id as cb_id, 
     vb.id as vb_id, 
     sb.id as sb_id, 
     v.id as v_id, v.name as v_name, 
     t.t1 as t1, t.t2 as t2, t.t3 as t3, 
     c.id, 
     SUM(t.amount) as t_amount 

     from t 
      join cb on t.cb_id = cb.id 
      join vb on cb.vb_id = vb.id 
      join sb on sb.id = vb.sb_id 
      join v on v.id = sb.v_id 
      join c on c.id=cb.c_id 

     GROUP BY 
      cb.id, 
      vb.id, 
      sb.id, 
      v.id, v.name, 
      t.t1, t.t2, t.t3, 
      c.id 
      ;

有了上述限制，我不能肯定它仍然甚至利用有益物化視圖更多，因爲刷新整個視圖每20第二個可能是沒有比一般的看法更好？我該如何優化這種情況？

來源

2014-08-28 Dreamer

每20秒刷新一次？這似乎有點反直覺了...如果這個腳本的運行時間超過10秒，那麼你的服務器花費了一半的時間來處理它。如果它在10秒以內，也許物化視圖不是要走的路？如果數據每20秒刷新一次，而不是每分鐘或2次，您的企業將獲得哪些收益？ – Twelfth 2014-08-28 21:46:56

@Telfelf謝謝。查詢需要大約一秒鐘的時間來返回所有結果，但我們需要每20秒重複一次以獲取最新結果。我們更喜歡使用視圖的原因是爲了避免只讀數據上的事務問題，最大限度地減少I/O。也可能有其他視圖加入這個基本視圖，它們不會花費幾秒鐘的時間返回結果，但仍需要每10-30秒刷新一次。 – Dreamer 2014-08-28 21:52:19

調用這個物化視圖多少次？如果每分鐘使用50次左右......我認爲這是有道理的。我猜，作爲第二個問題，您的索引是否良好，並在此方面得到充分利用？ – Twelfth 2014-08-28 22:36:49

根據我的經驗，物化視圖用於在主機系統不可用時接收服務器不能沒有數據的情況。我同意上面的評論，即每20秒刷新一次看起來過多，但如果這就是數據的作用，那麼這就是數據的作用。

例如，假設我們有一個訂單輸入系統和一個庫存控制系統。庫存控制系統保持庫存狀態（好，過期，損壞等）。訂單輸入系統需要知道需要訂購多少優質庫存。這對於物化視圖來說是一個很好的例子，因爲庫存狀態信息對訂單輸入過程至關重要。沒有它，訂單輸入系統將無法接受訂單，因爲它無法檢查狀態。

然而，在另一邊。假設相同的訂單輸入系統生成庫存報告，其中包括配送中心的庫存和訂單庫存。配送中心不知道訂單，所以我們只需同意訂單輸入系統是生成此報告的正確位置。如果我們不能生成報告，經理們可能會抱怨，但這不會阻止業務。這對於通過dblink的標準視圖來說是一個很好的例子。數據的使用並不重要，所以如果庫存控制系統出於某種原因停機，這不是什麼大問題，因爲訂單輸入系統可以在稍後運行報告。

對不起，如果我沒有真正回答你的問題，但希望它給你一些想法。

來源

2014-08-29 01:51:14 turboc

謝謝，我可以看到你的帖子的智慧。您的帖子中提到的「標準視圖」是指正常的非物質視圖嗎？在我的項目中引入m視圖的意圖只是爲了避免性能開銷。從正常觀點丟失數據不是問題。由於來自主表的數據是安全的，這一切都很好。它只是不確定刷新查詢與六個表連接在一起每20秒與10萬條記錄將導致甲骨文變得瘋狂（讓我們假設數據庫正確分配必要的資源）。 – Dreamer 2014-08-29 14:32:02

在這種情況下使用物化視圖還是普通視圖？

回答

相關問題