データベースの構造上のボトルネックを「見える化」する

高負荷時の問題

SQLのパフォーマンスは、どれだけの処理が同時に起こるかによっても変わってきます。特定のSQLの実行に関して負荷をかけることは、プログラムや設定によっても可能ですが、DB Optimizerのロードエディタを使えば、より簡単にSQLに特化した負荷状況を再現できます。

ロードエディタでは、SQL文を記述したり、SQLファイルを指定して特定のSQLを高負荷で実行します。実行にあたって、以下のようなオプションを設定できます。

• 並行して実行するセッションの数
• テストの長さ
• 実行数
• 実行間隔

SQL文を指定し、オプションを設定したら、プロファイリングを開始し、ロードエディタでロートテストを実行します。

ロードテストの効果

ロードテストを実行すると、特定のSQLの実行において、どのような処理に時間がかかっているか、また、それが他のセッションのSQLの実行にどのように影響を与えているかといった問題を理解できます。例えば、特定の処理が他のセッションを待機させるような状況を検出するのに役立ちます。

具体的には、頻繁にコミットを繰り返すような処理の場合、ログファイルへの出力処理で同期が発生し、これにより待機時間が大きくなる可能性があります。DB Optimizerのプロファイリング情報を確認すれば、こうした状況を視覚的に把握し、問題を取り除くことができるのです。

まとめ

ここまで見てきたように、SQLのパフォーマンス問題の解決は、単に「SQLの書き方を改善しましょう」というような単純な努力ではなく、もっと複雑な要因を分析して解決策を導く、困難な作業なのです。

特に問題をややこしくしているのは、その正解が、実際のデータやハードウェア構成、処理の頻度などによっても変わってくるということです。SQLパフォーマンス劣化を引き起こしている原因は、いくつもの複合要因が重なっており、それは状況によっても変化します。ひとつひとつの要素を分離して、具体的な対策を検討することは、膨大なログファイルでは不可能です。たとえ十分なスキルを持った熟練した技術者であっても、これらのログを読み取り、しかるべき方向性を打ち出すには、多くの工数を要してしまいます。そして、熟練技術者であればあるほど、その余計な工数はコストに跳ね返ります。

今回の例を見れば分かるように、パフォーマンスチューニングの絶対の正解というものはありません。それぞれの状況下で、何が影響するのかを分析できるようにする「見える化」が、最適解を導き出すために必要な道具なのです。

さて、ここでもうひとつの疑問が沸き起こるかもしれません。SQLパフォーマンスが、それぞれの状況下で異なる結果をもたらすのであれば、開発／テスト環境でのチューニングが、そのまま運用環境にも当てはまるとは限りません。

つまり、SQLパフォーマンスにより的確に対処するには、この両方の環境をまたいで、チューニングプロセスを考えなければなりません。

幸いなことに、DB Optimizerには、そうした機能が用意されています。次回は、開発から運用にわたるプロセス全体の中で、どのようにSQLパフォーマンス問題に対処するべきなのかを見ていきましょう