このページは、以下の英語ページの抄訳です。最新の情報については、英語ページを参照してください。

この記事のオリジナルは、Glenn Paulley がSybase.com に2008年4月に掲載したものです。

インストール可能なパッケージの一部としてデータベースシステムがアプリケーションに埋め込まれている場合、通常マシンのリソースを全て使うことはできません。

その上、設定やメモリの使用がインストレーションごとに、またその瞬間瞬間で異なる別のソフトウェアやシステムツールと共存する必要もあります。

アプリケーションのワークロード分析を実行して、サーバーのマルチプログラミングレベルなどのデータベース設定パラメーターを決定することはできるかもしれませんが、ある瞬間のメモリー量やシステムロードを予測するのは、とても困難です。

自己管理型のデータベースシステムでは、システムアーキテクチャー全体が自己管理のコンセプトにフォーカスされていなければなりません。

つまり、自己管理のテクノロジーを「アドオン」として提供するのは、ベースとなるシステムアーキテクチャーが効果的にその「アドオン」をサポートできなければ難しい、ということです。

例えば、SQL Anywhere では、サーバーのメモリーアーキテクチャーは、その他の多くの自己管理テクノロジーによって、可能になっています。

SQL Anywhere では、バッファープールの管理に以下のアプローチを使用しています：

アイソレーションでバッファープールを「チューニング」するのではなく、サーバーはバッファープールのon-the-fly のアロケーションをチューニングして、システム全体の要求にフィットさせます。

これは、フィードバックコントロールのメカニズムとOS のワーキングセットサイズを、一つのインプット （図参照） として使用することで行います。

毎分ポーリングされる OS ワーキングセットサイズは、プロセスによって使用されている、OSのリアルなメモリー量です。

このフィードバックコントロールループを使用することで、サーバーのバッファープールは、システム全体のリソースの使用とOS のメモリー管理ポリシーにより、オンデマンドで大きくなったり小さくなったりします。

フィードバックコントロールループの2つの参照インプット、OS ワーキングセットサイズと空いている物理メモリー、に加えて、バッファープールマネージャーは、バッファーミス率もモニタリングします。

ポーリング時間にバッファープールミスがない場合には、バッファープールガバナーは、バッファープールが大きくなることを許しません。

バッファープールページのリプレースメントが足りないということは、サーバーがアイドル状態であるか、データベースページのワーキングセットがバッファープールに完全にレジテントである可能性があることを意味します。

どちらの場合でも、そのサイズを大きくする必要はありませんが、バッファープールは、バッファープールのアクティビティに関わらず、新しいターゲットのバッファープールサイズが現在のサイズよりも小さい場合には、いつでも小さくなることが許されています。

SQL Anywhere の極めて画期的なことは、メモリーにレジデントであるバッファープールページは、4つのタイプのオブジェクトで使用されていることです：

(1) カタログオブジェクト（テーブル、ビュー、ストアドプロシージャー）を表すデータ構造;

(2) リクエスト、接続、connection-specific なオブジェクトのためのデータ構造を格納するヒープメモリー;

(3) クエリーメモリー。ソートや重複除去などのmemory-intensive なオペレーションのために使用されるワーキングメモリー;　そして

(4) データベースページ自身 (テーブル、インデックス、マテリアライズドビュー)

バッファープールマネージャーは、現在のワークロードと実行しているリクエストのタイプによって、バッファープールにそれぞれのタイプのメモリーをどれだけキープするかを動的に決定します。
プールのヘテロジニアスなコンテンツが、SQL Anywhere データベース内の全てのページが同じサイズでなければならない理由です。
特に、メモリーガバナーは、クエリーメモリーをある選ばれた数の memory-intensive なリクエストに割り当てます。
もしこの数がオーバーしている場合には、新しいmemory-intensive なリクエストは、（コンフリクトする）クエリーメモリー要求でサーバーが一杯になることを避けるためにキューイングされます。
また、SQL Anywhere は、ヒープメモリーがテンポラリーファイルにページングすることも許します。
これにより、全体メモリー需要を下げながら、サーバーが待機している接続をスワップアプトすることができます。

バッファープールサイズの変化性は、クエリーの最適化とクエリーの実行の両方にとって意味があります。
このような環境では、固定（静的）のアクセスプラン（DB2パッケージを考えてください）ではほとんど意味がありません。
なぜならば、サーバーのオペレーティングコンテキストは、瞬間瞬間で変更する可能性があるからです。
それゆえに、サーバーがリクエストを毎瞬間受け取らなくとも、クエリーは頻繁に最適化する必要があります。
そしてこれは、各クエリーの最適化のオーバーヘッドをできるだけ小さくするため、最適化のプロセス自体がチープである必要があることを意味します。
それゆえクエリーの実行プランは、利用可能な物理メモリーの合計内で変化する実行時間に適応しなければなりません。

結果として、SQL Anywhere のアクセスプランは、サーバーの処理環境の変更あるいはオプティマイザーによる推定エラーに対応して、実行時にいくつかのクエリー処理オペレーターや物理アクセスメソッドへの動的適応を可能にします。

まとめると、SQL Anywhere のアーキテクチャーでは、タンデムに機能する多岐に渡るクエリ処理メカニズムに、データベース管理者によるチューニングをほとんど、あるいは全くなしで、動的に合わせることが可能です。
例えば、ソートのために、特定のバッファープールをアロケーションする必要はありません。

これらのメカニズムにより、サーバーオペレーティングコンテキストとサーバーワークロードの両方の変更に自動的に合わせ、サーバーのバッファープールを必要に応じて大きくしたり小さくしたりすることが可能なのです。

===

SAP SQL Anywhere に関する詳細情報は、SAP SQL Anywhere Communityページ<英語> を参照してください。

上記のコミュニティーに掲載されている技術情報は、順次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」

を入力してください。

不具合につきましては、サポート契約者様専用の問い合わせ方法にてお問い合わせください。

======================
ご購入に関するお問い合わせ

こちらよりお問い合わせください。