開発のあいまに: インデックス・統計情報

2013年3 月18日 (月)

SQLServerで、IISからのDB処理だけが遅い現象が、どうしても解決しない場合は、ヒント文を使用する

SQLServerで時々発生する、IISや関連サービスからのDB処理だけが、極端に遅くなる現象に対応する為、４つのサイクルを回して来たのですが、運用時間帯に、一部の処理で、IISや関連サービスからのDB処理だけ、極端に遅くなる現象が再発してしまいました。

【４つのサイクル】
1、チューニングアドバイザーによる、インデックスと統計情報の抽出と追加。
2、テーブルの統計情報を、週次で更新。
3、ストアドとファンクションを、日次のジョブで毎朝リコンパイル。
4、IISと関連サービスを、日次で毎朝再起動。

【環境】
WEBサーバー：Windows Server 2008 R2 SP1
DBサーバー：Windows Server 2008 R2 SP1、SQLServer 2008 R2 SP2 CU5
WEBサイトは.Net4.0で構築

IISや関連サービスからだと数時間かかっている処理でも、SQLServer Management Studio から実行すると数秒で終わり、関連するストアドとファンクションをリコンパイルすると、IISや関連サービスからの処理も数秒で終わるようになるので、ストアドとファンクションがキャッシュしている実行プランに、問題があるのは確実なのですが、４つのサイクルでは解消しませんでした。

最終手段として、ストアドとファンクション内のSelect文が使用するインデックスを、ヒント文で固定する事で、解消することが出来ました。

具体的には、Management Studioから実行すると速い環境で使用されているインデックスを調査し、ヒント文でそのインデックスを固定する事で、どの環境でも必ず同じインデックスが使われるようにします。

【具体的な手順】
1、SQLServer Management Studio でSQLを右クリックし「推定実行プランの表示」を選択する。
2、表示された実行プランを右クリックし「実行プランのXMLの表示」を選択する。
3、表示されたXMLの中から「Index="」が有る行を検索する。
　XMLからだと、どのSelect 文のどのテーブルが、どのインデックスを使っているか、簡単に
　見つける事ができます。
　プライマリキーは無視して構いません。
4、見つかったインデックスは、ヒント文（ WITH (index( ）として、FROM句のテーブルの後に
　宣言し、そのSQLで使用されるインデックスを固定します。

ストアドやファンクションそれぞれの中で、各テーブルの別名を、ユニークになる名称にしていると、より簡単に対象のインデックスを見つける事ができます。

【ヒント文の例】
・1つのテーブルに1つのインデックスを指定する場合。
FROM （テーブル名） as （テーブル別名）
WITH (index(（インデックス名１）))

・1つのテーブルに複数のインデックスを指定する場合。
FROM （テーブル名） as （テーブル別名）
WITH (index(（インデックス名１）,（インデックス名2）))

※ヒント文に指定するインデックスは、NONCLUSTURED INDEX のみでよく、プライマリキーを含む CLUSTURED INDEX を指定する必要はありません。

SQLServerのインデックスと統計情報については、５つのサイクルを回す事で、パフォーマンスの問題を解決できそうです。

【５つのサイクル】

1、チューニングアドバイザーによる、インデックスと統計情報の抽出と追加。
2、テーブルの統計情報を、週次で更新。
3、ストアドとファンクションを、日次のジョブで毎朝リコンパイル。
4、IISと関連サービスを、日次で毎朝再起動。
5、IISと関連サービスからのDB処理が、極端に遅くなるストアド、ファンクションは、使用するインデックスをヒント文で固定する。

2013/03/18 8:22:59 | C#, Silverlight, SQL Server 2005, SQL Server 2008, Visual Studio 2010, WCF, Windows Server 2008, インデックス・統計情報, ビッグデータ

2013年3 月17日 (日)

SQLServer トレースフラグの有効性

DBサイズがテラバイトを超えて来ると、DB全体の統計情報を更新するだけで、1日以上かかってしまい、定期的な統計情報の更新を諦めていましたが、統計情報が更新されない事で、特定のSQLが極端に遅くなる現象が発生しました。

SQLを分解し、極端に処理が遅くなる原因となっていたテーブルを特定し、UPDATE STATISTICS を個別に実行する事で、実行プランが改善し Index Seek のコストが下がり、問題を解消することができました。

再発防止として、定期的に統計情報を更新したかったのですが、DB全体の統計情報を更新する事は不可能なので、トレースフラグが使えないか、検証環境で試してみましたが、、、
http://azwoo.hatenablog.com/entry/2013/02/14/125848
http://blogs.msdn.com/b/saponsqlserver/archive/2011/09/07/changes-to-automatic-update-statistics-in-sql-server-traceflag-2371.aspx

統計情報の更新が頻発し、運用時間帯の応答速度が著しく低下してしまったので、使い物になりませんでした。

その後、DBのデータ量の変化を調査し、95%程度のテーブルは、古いデータを定期的に削除するなどの対応で、データ量に大きな変化は発生せず、統計情報の更新は不要だという事が分り、残り5%程度のテーブルに絞れば、統計情報の更新時間を2時間程度に抑えることが出来たので、特定のテーブルを対象に、定期的に統計情報の更新を行うようにしました。

実データと統計情報の乖離が発生し易い、データ量の変化が多いテーブルのみに限定し、日次や週次といった、必要なタイミングで統計情報を更新する方が、トレースフラグよりも有効でした。