すべてのデータページをディスクのみに配置する必要があるSQL-SERVER 2016でクエリを実行するのにかかる合計時間を調べる必要があります。そのために、次のコマンドを使用してSQL-SERVERのすべてのバッファをクリアしました。
DBCC FREEPROCCACHE WITH NO_INFOMSGS
GO
DBCC DROPCLEANBUFFERS
GO
DBCC FREESESSIONCACHE
GO
DBCC FREESYSTEMCACHE ('ALL') WITH MARK_IN_USE_FOR_REMOVAL
GO
DBCC FLUSHPROCINDB (@dbId)
GO
この後、論理読み取りがそこにあることが再びわかり、先読みについて知るようになったので、トレースフラグによって先読みを無効にしました
DBCC TRACEON(652,-1)
GO
また、プリフェッチフラグ
DBCC TRACEON(8744,-1)
GO
今でも論理的な読み取りがありますが、物理的な読み取りは、バッファをクリアするだけの場合よりも大幅に高くなります。論理読み取りをゼロにする方法はありますか、または論理読み取りの私の理解は間違っていますか?
SQL-SERVERの世界は初めてです。
論理読み取りは、クエリの実行中にバッファキャッシュから単一のページが取得されたときにカウントされます。これは、ページのキャッシュに物理的または先読みが使用されたかどうか、またはページが既にバッファキャッシュに存在していたかどうかに関係なくカウントされます。結果として、論理読み取りは、クエリの実行中にメモリ内で実際にページが操作された回数の測定値です。
要求されたページがまだキャッシュにないため、ストレージエンジンがストレージから1つ以上のページを読み取るときに、物理読み取りがカウントされます。これには、先読みスキャンによって実行される物理的なIOは含まれません。
順次スキャン中にストレージエンジンがストレージから1つ以上の完全なエクステント(各エクステントは8つの連続したページ)を読み取ると、 先読み がカウントされます。先読み読み取りでは、データが積極的にメモリにプリフェッチされるため、クエリで必要になったときにページが既にキャッシュされている可能性があります。先読みスキャンによって読み取られるエクステントの数は、SQL Serverのバージョンとエディション、および断片化によって異なります。最新のSQL Serverバージョンを使用するEnterprise Editionでのスキャン中に、1つのスキャッターギャザーを使用して先読みスキャンが一度に4MBまで読み取るのを見てきましたIO.
SQL Server ストレージエンジンはコールドキャッシュで異なる動作をする (たとえば、再起動後またはDBCC DROPCLEANBUFFERS
)。キャッシュがまだウォームアップされていない場合(Buffer Managerのターゲットページが満たされた場合)、ストレージエンジンは、ページをキャッシュに読み込むために単一の8Kページ読み取りではなく、完全な64Kエクステント読み取りを実行します。これにより、他の場合よりもはるかに速くキャッシュが温められます。
クエリとインデックスのチューニングの目的では、物理的なよりも論理的な読み取りに焦点を当てることをお勧めします。これは、クエリによって実行される作業のより適切な尺度だからです。データがキャッシュされているかどうかは偶然です。コールドキャッシュを使用したテストは、クエリパフォーマンスであるIMHOよりもストレージパフォーマンスの測定値であり、ウォームキャッシュを使用する本番ワークロードで発生する状況を表すものではありません。
常に論理読み取りがあります。 SQL Serverがディスクから直接データを返すことはありません。必要なページがすでにバッファプールにある場合は、論理読み取りがあります。そうでない場合は、バッファプールに移動され、論理読み取りも行われます。読み取りは常にキャッシュから取得されます。
また、テストのポイントがわかりません。終末分析だけですか?空のキャッシュから開始して、データを返すまでの時間を単に測定しているのであれば、単に時間を測定していないのはなぜですか?論理的/物理的読み取りが心配なのはなぜですか?発行しているコマンドがプランキャッシュ/バッファプールをクリアすると思わない場合は、クエリを発行する直前にDMVを介してそれらを確認できます。
クエリのパフォーマンスを評価する場合、論理読み取りは非常に誤解を招く可能性があります。論理読み取りの増加は、パフォーマンスの低下を意味するものではなく、逆の場合もあります。