SAP SQL Anywhere におけるスナップショットアイソレーション(読み取り一貫性)とマテリアライズドビュー

この記事のオリジナルは、Glenn Paulley が sybase.com に2011年2月に掲載したものです。Glenn はこの中で、スナップショットアイソレーションとマテリアライズドビューを組み合わせて使用する効果について語っています。

===

私は以前の記事で、スナップショットアイソレーションの使用に関するトレードオフについて解説し、マテリアライズドビューの時間空間トレードオフに関する資料を紹介しました。スナップショットアイソレーションについての記事では、私は次のように書きました。

もちろん、スナップショットアイソレーションもタダではありません。データベースシステムは、新規のスナップショットトランザクションを見越して、変更されたデータのアーカイブコピーを作成しなければならないのです。SQL Anywhereでは、スナップショットのローのコピーは自動的に管理され、必要に応じて一時ファイルに書き込まれます（一時ファイルのサイズは必要に応じて増加）。管理上の影響はほぼゼロですが、クエリのパフォーマンスには影響が出る可能性があります。スナップショットのローを、トランザクションのスナップショットセマンティクスに従って、一時ファイルに保存されているスナップショットのローから個別にフェッチしなければならないためです。パフォーマンスがどの程度低下するかは、ひとえにアプリケーションとそのワークロードに依ります。更新量が多い場合には、パフォーマンスの低下はひどくなるでしょう。

今回の記事では、特にSQL Anywhereサーバのトランザクションログとの関連で、スナップショットアイソレーションとマテリアライズドビューの関係を解説し、そのトレードオフについても取り上げようと思います。

マテリアライズドビューをリフレッシュする

遅延メンテナンス型のマテリアライズドビューの場合、マテリアライズドビューの基となるベーステーブルへの変更は、追加のロックや（即時）メンテナンスのオーバヘッドなしに進行していきます。つまり、更新トランザクションはベーステーブルの値またはローを変更し、COMMITの時点でその変更を確定します。しかしこの状態では、マテリアライズドビューの内容は古くなってしまいます。このようなマテリアライズドビューの古い内容をSQL文が利用できるかどうかは、そのクエリの接続に関するオプション設定に左右されます。ビューの内容をリフレッシュするには、そのビューに対してREFRESH MATERIALIZED VIEW文を発行します。このSQL文は、事実上、対象のビューを含んでいるベーステーブルに対してTRUNCATE TABLEを実行した後、すぐさまINSERT … FROM SELECTを実行してマテリアライズドビューにデータを挿入します。

一方、即時メンテナンス型のマテリアライズドビューの場合には、最初にビューにデータを挿入する時にだけREFRESH MATERIALIZED VIEW文が必要です。それ以降は、基となるベーステーブルに変更を加えたときに、同じトランザクション内で、そのベーステーブルを参照している即時メンテナンス型のマテリアライズドビューに変更が適用されます。このトランザクションは、完了時にCOMMITを実行して変更を確定するか、ROLLBACKを発行して変更を取り消します。

===

（続きは、2011年に翔泳社 CodeZine に掲載された翻訳記事をご覧ください。）

SAPのSAP SQL Anywhere製品ページはこちら