大容量メモリ環境でのSQL Server TempDBの動作
読んでみよう この質問 は、少し前の質問を思い出しました。
512 GBのRAMを搭載したSQL Serverがあり、メインデータベースは450 GBです。 TempDBにはかなりの数のアクションが表示されます（わかりました、「かなりのアクション」です-そうではないかもしれません！）。 RamDisk Plus Serverのデモバージョンをインストールし、50GBのramdriveを作成し、TempDBをそれに向けましたが、パフォーマンスの向上はまったく見られませんでした。
TempDBへの書き込みは常にディスクへの実際の物理書き込みになりますか、それともWindowsファイルシステムキャッシュのように、TempDB書き込みは遅延書き込みのためにSQL Serverによってキャッシュされますか？
このシナリオではRAMディスクは無意味ですか？
SQL Server 6.5がTempDB-In-Ramをサポートしていたことは知っていますが、それはずっと前に廃止されたようです。
TempDBへの書き込みは常にディスクへの実際の物理書き込みになりますか、それともWindowsファイルシステムキャッシュのように、TempDB書き込みは遅延書き込みのためにSQL Serverによってキャッシュされますか？
彼らはいつもですか？ほとんど間違いなく。彼らは今までに？はい、しかし典型的なメカニズムの結果ではありません。ここでの参照は tempdbに対してチェックポイントは何をしますか？ です。
「正常に動作する」システムでは、ユーザーデータベースファイルへの書き込みはチェックポイントで発生します。不適切に動作するシステムでは、レイジーライターがバッファープールからページをフラッシュして他のページ用のスペースを確保する必要がある場合にも書き込みが発生します。
Tempdbのチェックポイントは、tempdbログファイルが70％に達したときにのみ実行されます。これは、tempdbログが可能な限り大きくならないようにするためです（長時間実行されるトランザクションは、本質的にログの人質を保持し、クリアするのを防ぐことができます）。 、ユーザーデータベースと同じように）。
ただし、tempdbでクラッシュリカバリが実行されることはないため、tempdbをディスクにフラッシュする必要はなく、起動時に常に再作成されます。
Tempdbはクラッシュ時に回復されないため、レイジーライタープロセス（バッファープールの一部）が他のデータベースのページ用のスペースを確保する必要がある場合を除いて、ダーティtempdbページを強制的にディスクに書き込む必要はありません。
これは驚くべきことに（私にとっては驚きでした）、tempdbページがディスクに書き込まれる唯一のメカニズムです。バッファプールの圧力がある場合、tempdbページがディスクにフラッシュされる可能性があります。ない場合は発生しません。
編集：「不正な動作」がチェックポイント外のページを書き込んでいるユーザーデータベースの適切な説明であるかどうかは、議論の余地があります。異常、非定型、または単に理想的ではないでしょうか？
追加編集（以下のコメント/ @ PaulWhiteとのチャット）：
上記の明白な省略は、一時テーブルがtempdbトラフィックの唯一のソースではないことです。 ハッシュ、ソート、交換のスピルイベントについて からの引用：
特定のSQL Serverクエリ実行操作は、中間記憶域として（やや）大量のメモリを使用することにより、最高のパフォーマンスを発揮するように調整されています。クエリオプティマイザーはプランを選択し、このメモリスクラッチパッドを使用してこれらのオペレーターに基づいてコストを見積もります。しかし、これはもちろん推定にすぎません。実行時に見積もりが間違っていることが判明する可能性があり、十分なメモリがないにもかかわらず計画は継続する必要があります。そのような場合、これらのオペレーターはディスクに流出します。
スピル操作の物理的な書き込みの背後にあるメカニズムは、前述のメカニズムとまったく同じであると誤って想定していました。つまり、レイジーライターは、バッファープールへの圧力の結果として（スピルによる）tempdbページをディスクに強制しています。
@PaulWhiteは私がどこが間違っていたかを説明しました（Paulに感謝します！）：
クエリがtempdb-in-memoryを使用するだけでなく、ワークスペースのメモリ許可を超えたときに物理tempdbアクティビティが発生する理由を尋ねていると思います。そうした場合、クエリは許可よりも多くのメモリを使用し、メモリを制限するポイントを無効にします。そもそも助成金。
流出は、書面から保管まで、実際に特別です。 tempdbの物理的な活動は、大量の空きメモリとtempdbへの圧力ゼロに直面しても、流出で見られます。
Paulは私に彼のブログ投稿 Advanced TSQL Tuning：Why Internals Knowledge Matters を指摘しました。これには、詳細を調べたい人のために、流出を示すためのサンプルスクリプトが含まれています。