クエリとストアドプロシージャを微調整しようとしています。私が直面している問題は、Azureのデータベースバッファーをクリアする方法がないということです。つまり、DBCC DROPCLEANBUFFERS
Azure。
ストアドプロシージャの実際の時間をテストできるようにバッファーをクリーンアップできる回避策はありますか?ページの平均余命を減らすことを考えていました(実際にそれができるかどうかはわかりませんが)。
ある記事でバッファがクリアされる可能性があると記載されていたので、DBの階層を変更してみましたが、効果がありませんでした。
ローカルマシン(8 GB RAMのI5)は速すぎ、ローカルマシンでの実行に1秒かかるクエリは、Azure S2(20 DTU)SQL DBで約30〜40秒かかるため、これが必要です。
あなたが基本的にしようとしていることは、クラウドのストレージ速度を測定することです。残念ながら、これは必ずしも再現性や信頼性があるとは限りません。騒々しい隣人、同じデータベースで開発を行っている他の人々、ストレージタイプなどによって異なる場合があります。
バッファをクリアしたり、クエリランタイムを測定したりするのではなく、論理読み取りの測定から始めてください。目標を達成するためにクエリが読み取る8KBページの数です。
SSMSまたはOperations Studioのいずれかで、次のコマンドを実行します。
SET STATISTICS IO ON;
次にクエリを実行し、各テーブルの論理読み取りの出力メッセージを調べます。これは、読み取った8KBページの数です。 (物理的な読み取りは無視します-キャッシュ内の内容に基づいて時々変更される可能性があります。)一般的に、少ないページの読み取りは、それらのページがメモリから読み取られたかディスクから読み取られたかに関係なく、より高速なクエリを意味します。
クエリが多くのテーブルを参照している場合は、電卓でそれらの数値を合計する代わりに、メッセージをコピーして StatisticsParser.com に貼り付けます。バッチ内の複数のステートメント間でさえ、全体的な論理読み取りの素晴らしい要約を提供します。 (免責事項:このオープンソースサイトは私の従業員の1人が作成したものですが、私の会社とは関係ありません。)