TempDBへの書き込みは常にディスクへの実際の物理的な書き込みになりますか、それともWindowsファイルシステムキャッシュのような遅延書き込みのためにSQL ServerによってTempDBの書き込みがキャッシュされますか?
彼らはいつもですか?ほとんど間違いない。彼らは今までですか?はい、しかし典型的なメカニズムの結果としてではありません。ここでの参照は、チェックポイントがtempdbに対して行うことです。。
「正常に動作する」システムでは、ユーザーデータベースファイルへの書き込みはチェックポイントで発生します。動作が不適切なシステムでは、レイジーライターが他のページのためのスペースを確保するためにバッファープールからページをフラッシュする必要がある場合にも書き込みが発生します。
チェックポイントは、tempdbログファイルが70%に達した場合にのみtempdbに対して実行されます-これは、可能な限りtempdbログが大きくならないようにするためです(長時間実行されるトランザクションでも、本質的にログの人質が保持され、消去されないことに注意してください) 、ユーザーデータベースと同じように)。
ただし、クラッシュリカバリはtempdbで実行されることはなく、起動時に常に再作成されるため、tempdbをディスクにフラッシュする必要はありません。
クラッシュの場合、Tempdbは回復されないため、レイジーライタープロセス(バッファープールの一部)が他のデータベースのページ用のスペースを作成する必要がある場合を除き、ダーティなtempdbページをディスクに強制する必要はありません。
これは驚くべきことでした(私にとって驚きでした)は、tempdbページがディスクに書き込まれる唯一のメカニズムです。バッファープールの負荷がある場合、tempdbページがディスクにフラッシュされることがあります。ない場合は、発生しないはずです。
編集:「不適切な動作」がチェックポイント外のページを書き込んでいるユーザーデータベースの適切な説明であるかどうかについては議論の余地があります。異常、非定型、または理想的ではないかもしれませんか?
追加の編集(@PaulWhiteとのコメント/チャットに続く):
上記の明白な省略は、一時テーブルがtempdbトラフィックの唯一のソースではないことです。ハッシュ、ソート、およびスピルイベントの理解からの引用:
特定のSQL Serverクエリ実行操作は、(ある程度)大量のメモリを中間ストレージとして使用することで最適に実行されるように調整されます。クエリオプティマイザーは、このメモリスクラッチパッドを使用して、これらの演算子に基づいてプランを選択し、コストを推定します。しかし、これはもちろん、単なる推定値です。実行時に推定が間違っていることが判明する可能性があり、十分なメモリがないにもかかわらず計画を続行する必要があります。このような場合、これらのオペレーターはディスクに流出します。
スピル操作の物理的な書き込みの背後にあるメカニズムは、前述したものとまったく同じであると誤って想定していました。
@PaulWhiteは私が間違っていた場所を説明しました(ポールに感謝!):
クエリがtempdb-in-memoryを使用するだけでなく、ワークスペースのメモリ許可を超えたときに物理tempdbアクティビティが発生する理由を尋ねていると思います。そもそも助成金。
流出は、実際に書面で保管まで特別です。空きメモリが多く、tempdbに負荷がかからない状態でも、流出時に物理的なtempdbアクティビティが見られます。
ポールはまた、彼のブログ記事「Advanced TSQL Tuning:Why Internals Knowledge Matters」に、流出を実証するためのサンプルスクリプトが含まれています。