4.11 性能評価とチューニング

運用フェーズに入った後のチューニング作業は、地道で困難な作業だと思われがちですが、データベースの状況を常に把握しておけば、事前にパフォーマンスの劣化を予期することもできます。
データベースの各コンポーネントの動作と相互間の連携の把握、OSとの連携処理の把握、ハードウェア（メモリ、CPU、ディスク）とネットワークの状態を常に管理しておくことが、パフォーマンスチューニングの早道ということができます。

カットオーバー後のメンテナンス作業としては、統計情報の収集（カットオーバー直後と定期的な収集が必要）とシステム使用環境の変化（アプリケーションの追加、ユーザ数、トランザクション数、データ量の増減など）を監視する必要があります。

統計情報の収集を随時行うことによって、パフォーマンスが悪化したときに、どこが変化しているのかを把握することができます。
変化した部分が、パフォーマンス劣化の原因になっている場合が多いのが現状です。
システムの内的な要因だけではなく、アプリケーションの追加やユーザ数の増加など外的な要因にも気をつけて情報を収集する必要があります。

ポイントは、統計情報からボトルネックの特定をする際、原因となっていそうな箇所が複数あっても、チューニングを行うのは必ず1つずつにするという点です。
一度に複数箇所をチューニングしたくなるのはわかりますが、それを行ってしまうと、どこが本当にパフォーマンスのボトルネックになっていたのか特定できず、根本的なチューニングにならなくなってしまいます。
ボトルネックを突き止めることによって、パフォーマンス劣化の原因も特定することができます。

最後に、データベースのパフォーマンスチューニングを行う際の順序を紹介します。
データベースのチューニングを行う際には、いきなりハードウェアの増強や、メモリの追加などを行うのではなく、SQLのチューニングから始めてください。
SQLに原因があるのに、ハードウェアを増強してしまうと、それによって一時的にチューニングできたように思えるかもしれませんが、根本的な解決には至っていないため、結局パフォーマンスの劣化は遅かれ早かれやってきてしまうことになります。

SQLのチューニングは、データベース管理者の役目の一部でもあります。
各表の統計情報の収集作業から始まって、表の構造や結合処理の方法を最適化できるように設計するのは、データベースのことを最もよく知っている管理者の役目です。

1. アプリケーションチューニング：
ユーザトレースを取得してSQL文のリソース使用状況、実行計画を確認する

• 索引が適切に使用されているか
• 結合のアルゴリズムは適切に選択されているか
• パラレル処理は適切に稼動しているか
• SQL文は共有化されているか

2. データベースサーバチューニング

• 断片化された領域の解消
• メモリ領域の拡弓尉縮小
• 競合の解消
• 大規模データを扱うときのパラレル化の検討
• DSS系の処理を行うときのマテリアライズドビューの使用の検討

3. ハードウェアのチューニング

• メモリの増設
• ネットワークの帯域幅の再考
• CPUのアップグレード
• IOのチューニング（ストライプ化の検討）

< 前へ　｜　4.11 性能評価とチューニング　｜ 次へ >