刷新數據倉庫中物化視圖的策略

我有一個系統，其中包含大約10億個物品的物化視圖，在一致的兩個小時的基礎上，我需要更新大約2億（20％的記錄）。我的問題是我的物化視圖的刷新策略應該是什麼？截至目前，它正在刷新一段時間。我很好奇在間隔刷新永遠刷新和重命名/替換舊的物化視圖與新的視圖之間的性能影響。潛在的問題是Oracle使用的索引創建了大量的重做。任何建議表示讚賞。刷新數據倉庫中物化視圖的策略

UPDATE
由於一些人似乎認爲這是題外話，我現在的觀點是要做到以下幾點：

創建Oracle附表鏈調用一系列的PL/SQL（編程語言，我的承諾）函數以僞平行的方式刷新物化視圖。但是，就像我陷入了某種類型的數據庫管理員那樣，我正在尋求用算法和/或某些代碼來解決數據問題。

來源

2012-10-20 Woot4Moo

帶關閉的問題。 – Woot4Moo

儘管如此，這不是一個編程問題。 – APC

另外，什麼激發你的好奇心？數據倉庫中是否存在需要解決的實際問題？ – APC

好吧，這是我提出的解決方案，你的里程可能會有所不同，任何反饋意見後，事實。總體戰略是要做到以下幾點：

1）利用甲骨文計劃利用鏈的並行執行的（工作）
2）利用視圖（正規的那種）從應用程序的界面到數據庫
3）依靠待建以下述方式

create materialized view foo 
    parallel 
    nologging 
    never refresh 
    as 
    select statement

根據需要使用物化視圖以下：

create index baz on foo(bar) nologging

的advantag這是因爲我們可以在刪除+重新創建視圖之前在後臺創建物化視圖，如步驟2中所述。現在，優勢是創建動態命名的物化視圖，同時保持視圖具有相同的名稱。關鍵是不要吹走原來的物化視圖，直到新視圖完成。這也允許快速下降，因爲有最小的重做要關心。這可以在5分鐘內在大約10億條記錄上創建物化視圖，這符合我們每三十分鐘刷新一次的要求。此外，這可以在單個數據庫節點上處理，因此即使受限制的硬件也是如此。

下面是一個PL/SQL函數，將創建爲您：作爲題外話是dba.se是在得到回答您的問題方面基本上是無用的

CREATE OR REPLACE procedure foo_bar as 
foo_view varchar2(500) := 'foo_'|| to_char(sysdate,'dd_MON_yyyy_hh_mi_ss'); 
BEGIN 
execute immediate 
'Create materialized view '|| foo_view || ' 
    parallel 
    nologging 
    never refresh 
    as 
    select * from cats'; 
END foo_bar;

來源

2012-10-23 22:26:18 Woot4Moo

您是否正在Oracle RAC或Exadata上運行此操作？如果您每次執行此操作時確實加載了1個bil項目，則必須具有非常強大的硬件。 –

@NWest我唯一知道的是它是16 cpus和〜128gb ram。 – Woot4Moo

刷新數據倉庫中物化視圖的策略

回答

相關問題