チューニングの基本は変わらない
プロセスダンプを取得し解析を行うにしても、動的管理ビューを活用するにしても、基本的なチューニングの考え方はあまり変わっていないと平山氏は説明する。
得られた内部情報などを基に、どの処理にどれだけ時間がかかったかをまずは洗い出す。次のステップでは、時間がかかっている処理について、その原因がCPUなのかディスクのIOに依存するのかを絞り込んでいく。
そして、処理としては特に問題がなく、たんにリソースが足りないだけなのか、あるいは処理が適切でなくリソースを食いつぶすクエリーが存在するのかといったことを見つけ出していく。最終的には得られた結果を基にSQLの最適化を行い、インデックスの設定や場合によってはテーブル構造そのものの見直しなどを施しチューニングを行う。これら対策を行ってもパフォーマンスが改善しなければ、さらなる対策としてメモリ量の増加や、ディスクIOの高速化なども検討することになる。
この一連のプロセスは、最新のSQL Server 2008 R2になっても大きく変わるものではない。新しくなって変わるのは、内部情報収集の方法や、それまで技術者の経験やノウハウだけに頼っていたことの多くが、SQL Serverの機能として自動化され、適宜システムからアドバイスを受け取れるようになったことだ。
「PSSDIAGとSQLdiagが揃ったことはSQL Serverにとって大きな変化です。これらの登場でユーザーにとってもサポートエンジニアにとっても、チューニング作業負荷が大きく軽減されました」（平山氏）
チューニング環境としては前述の動的管理ビューの登場が大きな転機だったが、さらにチューニング作業負荷の軽減に貢献しているのがPSSDIAGとSQLdiagという2つのツールの存在だ。SQLdiagはSQL Serverの標準管理ツールの1つ。コンソールアプリケーションまたはサービスとして実行でき、SQL Serverやその他のサーバーからログファイルやデータファイルを収集し、サーバーを一定期間にわたって監視したり、サーバーに関する特定の問題をトラブルシューティングしたりできる。
PSSDIAGは、MicrosoftのオープンソースプロジェクトCodePlexから入手できるツールで、パフォーマンスモニタログ、SQLプロファイラトレース、SQL Serverブロッキングスクリプトの出力、Windowsイベントログ、およびSQLdiagの出力を収集できる。SQLdiagとPSSDIAGを組み合わせて使えば、SQL Serverがどのような状況にあるかが、そのときのOSの状態も含め簡単に取得できるのだ。
