4.8 パーティションオプション、マテリアライズドビュー

まずイメージをつかみます。
図4-42は、実際にオンライン業務で使用している表に対して、分析に必要なデータを収集するために作成した、マテリアライズドビューを作成するためのSQL文を実行した状態です。

この例では、ファクト表に売上履歴表を指定し、ディメンション表である店舗、商品、時間表を結合して、店舗別_目別_商品別_売上サマリービューを作成しています。
アプリケーションによって、管理ポイントの粒度および管理項目の粒度は異なるので、必要に応じて複数のマテリアライズドビューを作成します。
ここでは、日別売上サマリーを作成していますが、月別サマリーが必要かもしれないし、商品別ではなく商品小分類別サマリーを作成する必要があるかもしれません。

すべての管理ポイント、すべての管理項目の一番小さい粒度で集計しておけば、それを実際に問い合わせるSQL文で集計すればよいのですが、パフォーマンスの観点から、ある程度の粒度であらかじめ集計しておく必要があります。

次に、作成されたマテリアライズドビューがどのように使用されるのかを見ます。

アプリケーションが実表に対するSQL文を発行すると（図4-43①）、SQLのリクエストを受け取ったサーバプロセスが最適化処理を行って、マテリアライズドビューに対するSQL文（図4-43②）への書き換え処理を行います。

書き換え処理を行うためには、コストベースオプティマイザが有効になっていること、適切な権限を実行ユーザがもっていること、マテリアライズドビューが利用可能状態になっていること、マテリアライズドビューに対するクエリーリライトが有効になっている必要があります。

リフレッシュのタイミングは、手動と自動の2つがあります。

手動の場合は、DBMS_MVIEWパッケージのプロシージャを実行したときにリフレッシュされます。
自動の場合は、リフレッシュのタイミングをCREATE MATERIALIZED VIEW文の中で指定し、2つの方法を選択することができます。
1つはCOMMIT時、もう1つはリフレッシュ開始時刻とその後のインターバルを指定することによって、定期的にリフレッシュを行う方法です。
リフレッシュの方法も、マテリアライズドビューを作成するときに指定します。

マテリアライズドビューは、スナップショットと同じメカニズムを使用しており、いくつかのリフレッシュオプションをサポートしています。

1つは、完全リフレッシュです。
CREATEコマンドを再実行することによって、既存データの切り捨てと元表に基づいた全データの再挿入が行われます。

高速リフレッシュでは、最後に実行されたリフレッシュ以降の変更がサマリービューに適用されます。
高速リフレッシュでは、2つのリフレッシュタイプが使用できます。
1つは、マテリアライズドビューログを使用した高速リフレッシュです。
実表に対する変更ログをすべて取得し、一定間隔で変更ログをサマリービューに反映させます。
もう1つは、ダイレクトパスロードを使用して新規行をロードする際に、ロードした行を高速リフレッシュさせる方法です。
このリフレッシュでは、SQL*Loaderのログが使用されます。

また、リフレッシュを行わないという選択も可能です。
アプリケーションの要件によって、適切なリフレッシュオプションを選択してください。

管理の面から、リフレッシュ処理に自動化処理を使用すると、ログの管理や障害時の復旧にコストがかかります。
また、制約が多い、障害時の対処などのメンテナンスに手間がかかる、特にCOMMIT時のリフレッシュは、オンライントランザクションCOMMIT時にレスポンスの悪化を引き起こす可能性もあるため、ユーザ要件が許すのであれば、リフレッシュ処理はなるべく単純化するのがコツです。

逆に、すべての分析業務が本当にリアルタイムで分析する必要があるのかを見直してみる必要がある場合もあります。
できれば、時間指定のバッチジョブで定期的に更新処理を行う仕様にするのがよいでしょう。

< 前へ　｜　4.8 パーティションオプション、マテリアライズドビュー　｜ 次へ >