このページは、以下の英語ページの抄訳です。最新の情報については、英語ページを参照してください。
https://blogs.sap.com/2013/05/24/from-the-archives-schema-design-tools-are-a-tough-challenge/
この記事のオリジナルは、Glenn Paulley が sybase.com に 2008 年 5 月に掲載したものです。
マテリアライズドビューは、データベース管理者のツールキットの中でも重要なものと考えられています。
マテリアライズドビューは事前演算されたビューです。一般的なテーブルとしてデータベース内に格納され、バッチのリフレッシュメカニズムを使用して最新の状態に更新される、あるいは、ベースとなるテーブルのビューを変更するのと同じトランザクション内で即時に更新されます。
ビューの即時更新が可能かどうかは、ビューの定義に依存しています – UPDATE、INSERT、または DELETE をベーステーブルのローのいずれに実行しても、そのシステムでは、これらの変更によって影響を受けるビューのローを正確に演算できなければなりません。
マテリアライズドビューの背景にあるマジックとは、クエリーオプティマイザーが、SQL クエリーで参照するベーステーブルのマテリアライズドビューを１つ以上代用でき、さらにそれを「自動的に」行えるということです。
ビューの代用は、ビューマッチングと呼ばれるプロセスで、クエリーオプティマイザーがコストベースで行います。
マニュアルでリフレッシュされるビューでは、そのビューから古いデータがクエリーされる可能性もあります。このような場合、必要に応じて、クエリー結果の相対的な古さをオプション設定またはクエリーテキスト自体で特定することが可能です。
SQL Anywhere でこれをコントロールするオプション設定は、マテリアライズドビュー オプティマイゼーション オプションです。
データベース管理者がマテリアライズドビューで解決しなければならない問題は、どのマテリアライズドビューを作成するべきかということで、学術的にはビューの選択性の問題と呼んでいる問題です。
どのマテリアライズドビューを作成するかを決定するのは、どのインデックスを作成するのかを決定するのに似ています。マテリアライズドビューをサポートしている主な商用システムの中には、インデックス選択管理ツールの中にビューの選択アルゴリズムを含めていまするものもあります。
しかし、ここで説明したいのは、現在どの管理ツールも考慮していない、ビューの選択の問題です。
テーブル R と S をそれぞれ変更するトランザクション A と B があると仮定します。実際、Ａと B は同じテーブルを参照しないかもしれません。そのため、コンカレンシーを実行しても、A と B との間にはロックコンテンションはなく、ほとんどあるいはまったくコンテンションはありません。
しかしながら、データベース管理者が、R と S を join するマテリアライズドビュー V を作成し、ベーステーブルとなるものいずれもの更新を反映して即時に変更する必要があると仮定します。
CREATE MATERIALIZED VIEW DBA.V ( C1, C2, C3 )
as
SELECT R.X, R.Y, S.Y
FROM R JOIN S ON ( R.X = S.X );
REFRESH MATERIALIZED VIEW DBA.V WITH ISOLATION LEVEL READ COMMITTED;
ALTER MATERIALIZED VIEW DBA.V IMMEDIATE REFRESH
この新しく作成されたマテリアライズドビュー V でトランザクション A と B を再度考えてみましょう。
A と B はコンフリクトする可能性があります。トランザクション A は、R のローを変更することができ、トランザクション B は S のローを変更することができます。しかしながら、これらの R と S のローが一緒になって V のローを構成しているのであれば、サーバーがビューを更新しようとしたときに、A または B のうちの片方は、ロー書き込みロックでブロックされます。
この即時マテリアライズドビューにおける ローロックコンテンションは、データベースにおけるあらゆる重要な更新アクティビティにおいて重要な問題になりえます。しかしながら、管理ツールにおけるこの現象のため、潜在的なコンカレンシーの問題を評価するのは非常に困難です。
なぜならば、マテリアライズドビューとインデックス選択ツールが可能な市販の製品はすべて、(1) 重複する文を省くことでワークロードをシンプル化する、(2) 複数回ワークロード内のそれぞれの文を処理して再最適化することに依存しており、もともとワークロードがキャプチャーされた時に存在していたタイミングへの依存（そのためあらゆるコンカレンシーの計測）を失うからです。
そのため、これら商用のビュー選択ツールでは、アップデートのコンテンションは考慮していないため、ビューの作成の方向に楽観的にバイアスされています。適切なパフォーマンス分析を事前に行わずにビューを本番に行うと、データベース管理者は、不意を突かれて驚くことになるので注意が必要です。
===
SAP SQL Anywhere に関する詳細情報は、<英語> を参照してください。
上記のコミュニティーに掲載されている技術情報は、順次
SQL Anywhere 日本語コミュニティ
に掲載しています。
SQL Anywhere に関してはまずは
こちらをご参照ください。無期限でご利用いただける無償の Developers Edition もこちらからダウンロードが可能です。
SQL Anywhere に関して技術的な質問のある方はコミュニティに登録し、
「Ask a Question」機能をご利用ください。
Language には「Japanese」、
Primary Tag には「SAP SQL Anywhere」を選択
User Tagに「sql anywhere」「sql anywhere Japanese question」
を入力してください。
不具合につきましては、サポート契約者様専用の問い合わせ方法にてお問い合わせください。
======================
ご購入に関するお問い合わせ
こちらよりお問い合わせください。
