このページは、以下の英語ページの抄訳です。最新の情報については、
英語ページを参照してください。
この記事のオリジナルは、Glenn Paulley が sybase.com に2009年11月に掲載したものです。この中で、Glenn は SQL Anywhere がデータベース管理者によるデータベースパフォーマンスのチューニングの必要なく動作するキーとなる機能、SQL Anywhere の統計管理の機能について語っています。
SQL Anywhere は、1992年 [1] から自動の自己管理の統計収集を提供しています。SQL Anywhere 12 では、さらに一歩進んで、SQL Anywhere のカラムヒストグラムを自己監視かつ自己治癒する統計ガバナーを実装しました。SQL Anywhere 12 における自己治癒統計管理には、以下が含まれます。
- クエリーの選択度推定エラーの記録とカテゴライズ
- 低オーバーヘッドでの統計エラーの自動・自律補正
- カラムヒストグラムのメンテナビリティーの自律監視と自律検出
エラーの特定
SQL Anywhere 12 では、サーバーはクエリー処理中の全サーチ条件における各述部と推定エラーの総計を監視します。
実際の選択度と推定選択度間の差は、不要な補正を避けるため、選択度が小さいエラーにはバイアスがかけられています。
この調整されたエラーで、サーバーは、そのカラムの述部の数とエラーの総数をベースにして各カラムヒストグラムのエラーメトリックを計算します。
このメトリックは、推定値と実際の値と間に大きな差が出る述部に好意的にバイアスがかけられ、エラーが20%から30%の間の場合にはステップ機能を含むように、また、エラーが35%より大きい場合には別のステップを含むようにします。
もし、計算されたメトリックがスレッシュホールドの値よりも大きい場合、そしてサーバーがそのカラムを含む述部に20よりも多く遭遇した場合、そのカラムヒストグラムは、補正候補として考えられます。
カラムヒストグラムの補正
サーバーがあるカラムヒストグラムに補正が必要だと決定した後、サーバーが自由に試みられる問題修正の方法は3つあります。
それらは、（試みる順番に）：
- 同じテーブルのデータへ他のクエリーを投げた際のカラム統計をピギーバックする;
- （インデックスがはられたカラムは）インデックス統計を使用して一からカラムヒストグラムを再作成する; そして
- Daemonプロセスを使用していて、サーバーが比較的アイドルな状態の間、自動でテーブルのサンプリングスキャンを実行する。
(1) で、サーバーは他のクエリーからのスキャンオペレーターを利用してカラム統計を収集しようと試みます。
（テーブルまたはインデックス） スキャンオペレーターが、テーブルの行の少なくとも70%を処理する場合、既存のヒストグラムはすぐにリプレースされます。
もしそれより少ない場合には、既存のヒストグラムは実際に遭遇した値の選択度をベースに調整され、そのテーブルの観察されていないパーセンテージに調整されます。
ストリングヒストグラムの場合は、リプレースと補正ポリシーは異なります。なぜならば、根底にあるヒストグラムの実装は、実質、数値から異なるからです。
おそらく、アプリケーションのワークロードがテーブルをソックリそのままスキャンするクエリーを含んでいないという理由で、もしサーバーがピギーバックされたスキャン経由で、更新された統計を収集できない場合には、サーバーは、プライマリーキー、外部キー、あるいはセカンダリーインデックスのアッパーレベルを使用してカラムヒストグラムの再作成を試みます。
もしカラムがどのインデックスのカラムもリードしていない場合には、最後の手段として、サーバーは、バックグラウンドプロセスを使用してテーブルをスキャンします。
このバックグラウンドプロセスは、テーブルのページの100%+1% の階層化テーブルスキャンを実行します。
サンプリングは、テーブルページを
n の等しいサイズのブロックにパーティショニングすることで行います。
n は、サンプルするページの数です。
そして、サーバーは、ランダムに各ブロックから、一つのサンプルページを選択し、リプレースするヒストグラムの計算に使用します。
統計使用の自己監視
サーバーは、更新されたヒストグラムを ISYSCOLSTAT カタログテーブルに、少なくとも30分間 （そして毎
CHECKPOINT）自動的に保持します。
これは、
統計フラッシャーと呼ばれるDaemonによって実行されます。
上記の自己治癒メカニズムに追加して、SQL Anywhere 12 には、
統計クリーナーと呼ばれる統計監視Daemonが含まれており、統計エラーをずっとトラッキングします。
もし監視しているDaemonが、とある特定のヒストグラムはエラーメトリックが継続的に高いので継続的にリビルドが必要であると決定した場合には、Daemonは自動的に
DROP STATISTICS 文を実行して、そのヒストグラムの自動作成を無効にします。
そのヒストグラムが利用不可能でも、クエリーオプティマイザーは、主に同時実行接続からのデータ内の過度な同時「撹拌」によって発生するヒストグラムに含まれる（誤った）値を利用するよりもむしろ選択度推定のインデックス統計またはマジック値に排他的に依存します。
そして後で、サーバーは上記3つのうちのどれか一つの復元方法を使用して、異常を修正しようとして自動的にカラムヒストグラムを再作成します。
我々の経験では、SQL Anywhere の自己管理統計管理は、堅牢で、広い範囲のワークロードや更新シナリオをハンドリングできます。
必要であれば、データベース管理者が、様々な側面の統計収集を制御できるだけでなく、統計フラッシャーと統計クリーナープロセスでも制御できることも真実です。
どちらのタスクの動きも、
sa_server_option システムプロシージャーを使用することでカスタム可能です。
[1] I. T. Bowman et al. (April 2007).
SQL Anywhere: A Holistic Approach to Database Self-Management. In Proceedings, 2nd International IEEE Workshop on Self-Managing Database Systems, Istanbul, Turkey.
===
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」
を入力してください。
不具合につきましては、サポート契約者様専用の問い合わせ方法にてお問い合わせください。
======================
ご購入に関するお問い合わせ
こちらよりお問い合わせください。S
