キャプチャと再生のワークロード
新しいサーバーも移行しており、ハードウェアの潜在的な利点を確認したいと考えています。つまり、ワークロードを取得し、これを新しいボックスに対して再生するという考えです。
しかし、私の質問は、パフォーマンスの利点を確認することです。いくつかのパフォーマンスカウンターを実行しますが、理想的には、個々のクエリがどれだけ速いかを確認したいと考えています。
この情報は最初のワークロードキャプチャに含めますが、新しいサーバーでこれを再生するときに、トレースを実行して新しいワークロード情報もキャプチャする必要があります。実際には、SQLプロファイラーを同時に2回実行して、再生とキャプチャを行っていますか？
これを行う必要があるたびに、RMLユーティリティを使用しました（x86およびx64パッケージのダウンロードリンクは このページ にあります）。
基本的には、パッケージに含まれているテンプレートの1つを使用してサーバー側のトレースを設定するだけです。キャプチャされたトレースは、ReadTrace（RMLユーティリティに含まれる）を使用して分析でき、クエリ分析結果をデータベースに入力します。結果は、Reporterと呼ばれるツールを使用して表示されます。これは、RMLユーティリティ用に再パッケージ化されたレポートサービスです。
ReadTraceは、新しいインスタンスに対する再生に使用できるRML中間ファイルも生成します。再生用のツールはOstressと呼ばれます。
再生（またはキャプチャ）を試行する前に、マニュアルをよく読んで、キャプチャをバックアップと同期させ、ワークロードが同じデータに対して実行されるようにして、一貫した結果が得られるようにする必要があることを理解してください。
再生を実行する前に、最初のキャプチャに使用したのと同じテンプレートを使用して、新しいインスタンスにトレースを設定します。再生が終了したら、ReadTraceを使用してワークロードを分析し、Reporterの比較機能を使用できます。 CPU、経過時間、I/Oの2つのキャプチャで改善または悪化したクエリが表示されます。
些細なことではありませんが、多少の忍耐と少しの試行錯誤で実現できます。幸運を！
PS：RMLユーティリティの新しいバージョンでは、拡張イベントを使用してキャプチャされたワークロードを分析することもできます。私の経験では、この方法ではファイルが大幅に大きくなります。 RMLと分散再生で使用されるトレーステンプレートは異なるため、相互に交換して使用しないでください。正しく思い出せば、拡張イベントファイルを使用して分散再生をフィードする方法はありますが、間違っている可能性があります。私の意見では、これは、Ostressが高度な並行ワークロードに対応できない場合にのみ調査する必要があるオプションです。
Microsoft Database Experimentation Assistantを試してください： https://www.Microsoft.com/en-us/download/details.aspx?id=5409 各クエリに基づいてパフォーマンス情報を提供できます。