ワークスペースメモリの内部

クリスチャンボルトン、ブレントオザールなどによるSQL Server 2008の内部とトラブルシューティング（イリノイのローカルライブラリから借用）に関する本を読んでいます。私の理解を確認または修正できます。

クエリメモリの付与を必要とするすべてのクエリまたは操作には、ワークスペースメモリが必要です。並べ替え、ハッシュ一致結合、並列処理（これについては不明）、一括挿入（不明）、インデックスの再構築などを使用した一般的なクエリでは、クエリワークスペースメモリが必要です。

ワークスペースメモリはSQL Serverバッファプールの一部であり（バッファプールの一部として割り当てられます）、最大ワークスペースメモリはバッファプールに割り当てられたメモリの75％です。既定では、1つのクエリでワークスペースメモリの25％を超える値を取得することはできません（SQL 2008 / SQL 2012では、リソースガバナーの既定のワークロードグループによって既定で制御されます）。

私の理解の確認を求めて

1）48 GB RAMと最大サーバーメモリが40 GBに設定されたシステムを考えると、これは最大ワークスペースメモリが30 GBに制限され、1つのクエリで10 GBを超えるワークスペースメモリ（クエリメモリ）を取得できないことを意味します。したがって、大量のハッシュ結合を実行している10億行で動作する不適切なクエリがあり、10 GBを超えるメモリ（ワークスペースメモリ）が必要な場合、このメモリ許可キューを介しても、すぐにディスクに流出しても問題ありませんか？

2）大量の並べ替え操作を行うクエリに5 MBのワークスペースメモリが割り当てられ、クエリのクエリ実行中に、クエリオプティマイザが悪い統計またはインデックスの欠落により実際に30 MBのワークスペースメモリを必要とする場合すぐにtempdbに流出します。実行中にシステムが十分なワークスペースメモリを使用できる場合でも、実行中にクエリが許可されたワークスペースメモリを超えると、ディスクにスピルする必要があります。私の理解は正しいですか？

このメモリ許可キューを通過したり、すぐにディスクに流出したりすることさえ気になりますか？

それはそのようには機能しません。メモリ許可を必要とするプランが選択されると、クエリは許可を取得してキューを通過する必要があります。流出は、もしあれば、実行サイクルのずっと後に発生します。クエリは、許可なしで先に進むことを決定できず、代わりに「流出」します。それは許可を取得する必要があり、ベースはそれを実行し、実行を開始します。助成金が不十分であることが判明した場合（推定値が悪いため、または要求よりもはるかに低い許可を取得したため）、クエリは強制的にスピルされます。

クエリオプティマイザーが統計の不良またはインデックスの欠落によりそれを認識した場合

厳密に言えば、オプティマイザーではなく、クエリの実行です。クエリオプティマイザーにはプランを決定する権限がありますが、プランを選択して実行を開始すると、オプティマイザーは見えなくなります。また、「インデックスの欠落」はここでは役割を果たしません。インデックスが見つからないと悪いプランを強制することができますが、そのプランは実際に存在するインデックスを正確に考慮して構築されているため、その「悪い」プランの実行方法に影響を与えることはできません。流出は、ほとんどの場合、推定値が悪いために発生します。オプティマイザーと実行における悪い統計またはカーディナリティー推定アルゴリズム（詳細を掘り下げると複雑になりますので、ここで停止します）。

実行中にシステムが十分なワークスペースメモリを使用できる場合でも、実行中にクエリが許可されたワークスペースメモリを超えると、ディスクにスピルする必要があります。

残念ながらそうです。ただし、オプティマイザーは、使用可能なRAMを活用する計画を立てるがあります。

私は読んでお勧めの理解SQLサーバーのメモリ許可することによって、対象で最高の情報である広いマージン。