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時間程度に抑えることが出来たので、特定のテーブルを対象に、定期的に統計情報の更新を行うようにしました。
実データと統計情報の乖離が発生し易い、データ量の変化が多いテーブルのみに限定し、日次や週次といった、必要なタイミングで統計情報を更新する方が、トレースフラグよりも有効でした。
コメント