web-dev-qa-db-ja.com

SQL Serverベースラインテストの手順の決定的なリスト？

SQL Serverを使用するアプリのパフォーマンステスト/ベースラインを実行する前に、インスタンスを再起動せずにインスタンスを「クリーン」な状態に設定できるようにしたいと考えています。私は従う傾向があるステップがありますが、正しい順序であり、冗長なステップがない決定的なリストを作成したいと思います。

この手順の一覧では、SQL Serverを「クリーン」な状態に設定できますか？

シーケンスは論理的/正しいですか？

余分な手順はありますか？

CHECKPOINT              -- Write all dirty pages

DBCC DROPCLEANBUFFERS   -- All should be clean after checkpoint?

DBCC FREEPROCCACHE      -- Clear the plan cache

DBCC FREESYSTEMCACHE    -- Is this necessary after FREEPROCCACHE?

DBCC FREESESSIONCACHE   -- May not be necessary if distributed queries aren't used, but want to catch all scenarios

EXEC SP_UPDATESTATS     -- Refresh stats

'BEGIN TESTING!'
sql-serverdbccperformancecacheperformance-testing
10
Eric Higgins

まず、一歩下がって、テスト中に収集する予定の測定値を尋ねます。たとえば、クエリで論理読み取りをカウントしている場合、キャッシュを解放する必要はありません。データがキャッシュされているかディスク上にあるかに依存しないため、論理読み取りを使用するのが大好きです。また、運用環境では、クエリのデータがキャッシュされるかどうかを推測することはできません（データベース全体をメモリにキャッシュしない限り） 。論理読み取りを最小限に抑えるように調整すると、データがキャッシュにあるかどうかに関係なく、アプリはより高速になります。

次に、実行間で何が変わっているのか質問します。たとえば、提案したように各データベースでEXEC SP_UPDATESTATSを実行することにより、更新されたテーブルの統計をリサンプリングします。ただし、フルスキャンで統計を更新しない限り、テーブルからランダムな行が取得されます。これは繰り返しが多すぎないため、本当に実行する必要はないと思います。代わりに、実行のたびにデータベースを復元して、常にまったく同じデータをテストすることをお勧めします。テストが挿入/更新/削除を行っている場合、データベースを復元しないと（データを追加/変更し、さらにデータの統計を変更するため）、実行ごとにパフォーマンスプロファイルが異なる可能性があります。さらに悪いことに、同じ値に対して繰り返しデータを挿入しようとすると、クエリが失敗する可能性があります。

5
Brent Ozar