9.6 アプリケーションのチューニング
現実問題として，「アプリケーション設計はシステムの性能を大きく左右する」という純然たる事実に思いが至っていない開発事例は少なくない。サーバーはクライアントからの要求に応えて利用可能なリソースを割り当て，処理を実行する。その意味では，「まず最初にクライアントありき」なのであり，より踏み込んでいえば「実際に要求を出すクライアントアプリケーションありき」なのである。にもかかわらず，アプリケーション設計が不適切な事例が多々見られる。たとえば，本来であればサーバー側で処理すべき機能をクライアント側のアプリケーションに実装してしまった（Fat Client化）ため，処理の終了まで長時間かかってしまい，性能問題を引き起こしている例が少なくない。実際，データベースシステムの性能問題が発生しているのでアプリケーション設計を見直して修正したところ，大幅に性能が改善した例も多数ある。
一般的に，データ固有の処理はデータベースサーバー上ですべて実行し，処理能力の低いクライアント上のアプリケーションでは，ユーザーからのデータを入力したり表示したり更新したりという機能を実装するにとどめるべきである（Thin Client化）。また，クライアントとサーバーとのあいだでやり取りされるデータ転送量を減らすため，クライアントアプリケーションに渡すデータをサーバー側で絞り込んでからクライアント側に転送する必要もある。つまり，クライアントアプリケーションでは，データ抽出条件をできるだけ厳密に定義すべきといえるだろう。
SQL Serverにアクセスしているアプリケーションの性能が問題となっているときは，アプリケーション設計を検証する。アプリケーションには，クライアントアプリケーションとサーバーアプリケーションの2種類があるため，両者を切り分けて，どこに問題があるのかを絞り込むことが重要である。また，アプリケーションプログラム全体を問題にしているのか，データベースアクセス部分のみを問題にしているのかも，分けて考えなければならない。
アプリケーション設計を検証するときには，一般的には次のような手順で実施する。
- SQL Serverプロファイラなどを利用して「遅いクエリ」あるいは「遅いアプリケーション」はどれかを識別する
- SQL Serverクエリアナライザを利用してクエリの実行計画を分析する
- クエリの実行計画分析の結果，ディスクI/Oがボトルネックであれば，インデックスチューニングウィザードを利用してインデックスを評価する。また，インデックスの統計を分析する
- クエリの実行計画分析の結果，ディスクI/O以外にボトルネックであればクエリを見直す
- クエリに問題がなければ，クエリ以外のアプリケーションロジックおよびコードを見直す
- 複数のアプリケーションが同時に稼働しているのであれば，ブロッキングとロックの競合を検証する
 |
Chapter 9 9/46 |  |
