5

私は約 10 億のアイテムを含む具体化されたビューを持つシステムを持っています。一貫して 2 時間ベースで、約 2 億 (レコードの 20%) を更新する必要があります。私の質問は、具体化されたビューの更新戦略はどうあるべきですか? 現在のところ、間隔をあけてリフレッシュしています。インターバルでリフレッシュすることと、古いマテリアライズドビューの名前を変更/新しいものに置き換えることとの間のパフォーマンスへの影響について興味があります。根本的な問題は、大量の REDO を作成する Oracle によって使用されるインデックスです。任意の提案をいただければ幸いです。

更新
これはトピックから外れていると考える人もいるようなので、私の現在の見解は次のことです。

一連の PL/SQL (私が約束するプログラミング言語) 関数を呼び出してマテリアライズド ビューを疑似並列方式で更新する Oracle スケジュール チェーンを作成します。しかし、私は一種の DBA の立場に落ちたかのように、アルゴリズムやコードを使用してデータの問題を解決しようとしています。

4

1 に答える 1

2

わかりましたので、これが私が思いついた解決策です。走行距離は異なる場合があり、事後のフィードバックは大歓迎です。全体的な戦略は、次のことを行うことでした。

1) チェーン (ジョブ) の並列実行を利用する Oracle Scheduler を利用する
2) アプリケーションからデータベースへのインターフェースとしてビュー (通常の種類) を利用する
3) 次の方法で構築されるマテリアライズド ビューに依存する 

 create materialized view foo  
    parallel  
    nologging  
    never refresh  
    as  
    select statement

必要に応じて、次を使用します。 

   create index baz on foo(bar) nologging

これの利点は、ステップ 2 で説明したように、ビューを削除して再作成する前に、バックグラウンドで具体化されたビューを構築できることです。この利点は、同じ名前のビューを維持しながら、動的に名前が付けられた具体化されたビューを作成することです。重要なのは、新しいマテリアライズド ビューが完成するまで、元のマテリアライズド ビューを吹き飛ばさないことです。これにより、気にする必要のあるやり直しが最小限になるため、迅速な削除も可能になります。これにより、約 10 億レコードのマテリアライズド ビューを 5 分で作成でき、30 分ごとに「更新」するという要件を満たしました。さらに、これは 1 つのデータベース ノードで処理できるため、制約のあるハードウェアでも処理できます。

これを作成する PL/SQL 関数を次に示します。 

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-23T22:26:18.017 に答える