SQL文収集機能

データベースのチューニングで、もっとも効果的なのがSQLのチューニングです。初期化パラメーターのチューニングで100倍速くなることはめったにありませんが、SQLのチューニング(インデックスを含む)ではよくあることです。またパフォーマンスに関するトラブルの多くは少数のSQLに起因しています。

 つまりSQLにこだわることが重要です。SQL文収集機能では、実行しているSQLを収集し、同時にその統計データも取得します。そして問題のあるSQLを突き止め、その解決に大きな力を発揮します。

問題のあるSQLを容易に発見

SQLトレース画面

Performance Analyzer 4のSQLトレース機能では、データベースで実行しているSQLを指定した一定間隔(1/1000秒単位)で取得します。それ以外にも、SGAに載っている全SQLを取得することもできます。

 取得できるSQLは、単独のSQLに加えて、ストアドプロシージャから発行したSQLも含まれます。また同時に統計データや実行計画も取得します。これらの取得したSQLを、平均実行時間や平均ディスク読み取り数などの切り口で調べることで、問題となるSQLを発見します。

よりリアルな時間を計測

SQLの実行時間は、Statspackを初めとする多くのツールでは、データディクショナリの値を利用し elapsed_time/executions(累計経過時間/実行回数) という計算式で算出します。

 このときの問題点は、elapsed_timeはデータベース上の累計経過時間だということです。elapsed_timeを実行回数で割ることで1回の実行時間を求めているため、実行時間にばらつきがある場合には対応できません。またelapsed_timeはデータベースだけで要した時間なので、ネットワークや画面表示にかかった時間は含まれません。そのため実際の体感時間と大きく懸け離れた値になることがあります。

 たとえば次のような大きなテーブルをselectすることを考えてみます。実行時間はSQL*Plusのset timing onコマンドで計測します。
SQL> select * from big_table;
経過: 00:01:37.43
 すると約1分37秒かかりました。次にデータディクショナリ上のelapsed_time/executionsの値を計算すると0.057秒しかかかっていません。なぜなのでしょうか。

 これはelapsed_timeがデータベース上でかかった時間だけだからです。大量データをselectすると、ネットワークや画面処理に多くの時間を取られるため、elapsed_timeでは体感時間と懸け離れた値になってしまいます。

 Perfomance Analyzer 4では、独自のポーリングテクノロジーにより、アプリケーション上の体感時間に近い値を予測します。また同じSQLの実行時間のばらつきも検知できます。

強力なSQLチューニング支援機能

SQL解析画面

問題となるSQLを発見したら、すぐにチューニングです。SQL解析機能を使えば、SQLの実行計画や実行統計などを簡単に取得でき、SQL文の修正やヒントの追加、インデックス追加など、簡単にチューニングできます。

列のデータ分析

QLチューニングのポイントはインデックスです。どこにインデックスを張ればよいか、どのようなインデックス構成にすればよいかを慎重に考慮しなければなりません。チューニングツールの中には、自動的にインデックスを作成するものもありますが、安易なインデックス作成は更新パフォーマンスに影響を及ぼすこともあり、のちのメンテナンス性も悪化させます。  またインデックスを作成するための参考情報として、実行計画以外にも、対象となる列データのカーディナリティや分布(ヒストグラム)など、さまざまな情報を提供します。

実行計画の比較

実行計画の比較

ある日突然遅くなった、というのはよくある出来事です。原因はさまざまですが、よくあるのは実行計画が変わったことによるパフォーマンスの劣化です。実行計画が変わる要因としては、データベースのアップグレード、統計情報の更新、初期化パラメータの変更、バインドピークによる挙動などがあります。

 ただし実行計画が変わったSQLを識別するのは簡単ではありません。実行計画の比較機能を利用し、取得したSQLトレースのデータを比較することで、実行計画が変わったSQLを簡単に識別できます。これはデータベースのアップグレード前後の検証でも有効です。

バッファキャッシュの内容を表示

バッファキャッシュ内の表示

Oracleを初めとする本格的DBMSの特長として挙げられるのがバッファキャッシュです。DBMSが独自にキャッシュメモリを持つことで、より高いパフォーマンスを実現しています。

 しかしながら万能ではありません。たとえば、めったにアクセスしない大きなオブジェクトを検索すると、キャッシュ上にあった頻繁にアクセスするオブジェクトがキャッシュアウトされてしまう可能性があります。また似たようなインデックスを大量に作成した結果、それらのインデックスにバッファキャッシュが埋め尽くされてしまう可能性もあります。

 そのため、高度なデータベースになるほどバッファキャッシュのチューニングが不可欠です。バッファキャッシュに載っているオブジェクトやサイズ、頻度などを表示できるので、バッファキャッシュのチューニングを大幅に効率化します。マルチプルバッファプールにも対応しています。