SQL Server パフォーマンス調査の定石 - 1. 現状 -

去年のイベントで SQL Server のパフォーマンス調査について話をする機会がありました。幾つかのエントリに分けて、この時に話した内容+α を文章で纏めていきたいと思います。

http://www.slideshare.net/kosasaki/sql-server-deep-dive

2014年に説明した内容ではあるものの、別に新しいバージョンでのみ適用できるパフォーマンス調査方法という訳ではありません。むしろ SQL Server のパフォーマンス調査の手法やツールセットは SQL Server 2005 で既にほぼほぼ整備されており、SQL Server 2005 / 2008 (R2) / 2012 / 2014 / 2016 で殆ど変わりません。いや、もちろん新しい機能は続々追加されているので、個別個別のケースへの対処は必要ですが、基本となる方法論は変わらないと考えています。

今も変わらない (と私は思っている) 基本的な手法は、もう出版されて 10 年近くになりますが、古くは「Inside Microsoft® SQL Server(TM) 2005: T-SQL Querying」という本にも書かれていたりします。2009 年には「インサイドMS SQL SERVER 2005 T-SQL編 (マイクロソフト公式解説書)」という名前で 熊澤さん監修の翻訳版も発売されています。とても良い本です。

もうだいぶ以前からパフォーマンス問題の原因を特定するための手法やツールも整ってきている、と個人的には感じてはいるのですが、SQL Server のパフォーマンス問題への対処の基本的なところで詰まっている状況によく出会います。そのような状況になる理由は様々あると思いますが (*)、解決可能そうな以下 2 点について考えてみたいと思います。

  1. 「用意されたツールセット」を使用して実際に問題解決できる状態に至るまでに壁がある
  2. 「パフォーマンス問題対処の手法」を把握して実際に問題解決できる状態に至るまでに壁がある

(*) 大規模データベースを含む開発プロジェクトなのにテスト期間が殆どないとか、本番データの 1/100 スケールでテストしてサービスインに臨むとか、そもそも DBA なんていないとか、そういうのは横に置いておきます・・

1. は製品バージョンアップを経て改善されている部分もあると思います。SQL Server 2005 で動的管理ビュー (DMV) と利用状況モニタが整備され、SQL Server 2008 では「パフォーマンス データ コレクション」が追加されてお手軽に GUI で過去に遡ってパフォーマンス調査できるようになりました。SQL Server 2012 では個別ケースの問題調査をするための非常に詳細な情報が取得できる拡張イベントも大きく改善されました。しかし、せっかく追加された機能が実際のシステム開発の現場で使用されていない、という状況は往々にしてあると感じています。この点、便利な機能を より周知し、ユースケースやベストプラクティスを広めていく必要がありそうです。

2. もよく目の当たりにする問題です。着実にパフォーマンス問題を特定していく手段はあるのですが、実際の現場では「あれ?ロック待ちじゃね?ブロッキングの情報取ろう」「いや、とりあえずパフォーマンスカウンター見よう。このカウンターの値 大きくなってるから原因じゃね?」 といったように断片的・断面的な調査が行われて右往左往しているケースを本当によく見かけます。本来ほとんどのケースで必要ない 『SQL サーバートレース (SQL Server プロファイラ) の情報を大量に取って長時間かけて調査している状況』もよく見かけます。2. についても 1. と同様に手法のブラッシュアップと周知が必要かもしれません。

次のエントリからパフォーマンス問題対処の手法について纏めていきたいと思います。