MAX_IOPS_PER_VOLUMEで「ボリューム」とはどういう意味ですか？
リソースプール にMAX_IOPS_PER_VOLUMEを設定する場合、「ボリューム」とは正確にはどういう意味ですか？具体的には、「ボリューム」の数は次の場合になります。
- 2つのパーティションE：とF：に分割されたローカルに接続されたディスク
- ソフトウェアRAID1セットE：2つのローカルに接続されたディスクで構成されます（はい、ソフトウェアRAIDが悪いことはわかっています。このケースを追加すると、本番セットアップを設計するのではなく、SQL Serverの「ボリューム」の定義を理解するのに役立ちます！）
- ハードウェアRAID1セットE：ローカルに接続された2つのディスクで構成
- SANディスクE：ディスクの数を誰が知っているか/誰が気にかけているか。
- ローカルに接続された2つのディスクE：およびF：にまたがる1つのSQLServerファイルグループ
＃3と＃4の答えは「1巻」、＃5は「2巻」だと思いますが、一番気になるのは＃1と＃2です。
私が尋ねている具体的な理由は、ローカルに接続されたSSD tempdbのリソースガバナーのIOPS制限を、SANデータストレージの下限を設定しながら、増やすことができるかどうか疑問に思っています。
したがって、単一の物理ディスクを複数のパーティションに分割することがこれを行う方法であるかどうか疑問に思っています。各パーティションに個別のtempdbファイルを配置して、合計tempdbが上記の＃1の場合、SQLServerが1つの物理ディスクをスロットル用の複数のボリュームとして扱うようにします。目的のために、これはオプションかもしれません。これは機能しないと思います-SQL Serverは、2つのパーティションが1つの「ボリューム」であることを認識できるほど賢いです。しかし、尋ねる価値がありました。
「ボリューム」は、ドライブ文字、またはSQLServerのrawパーティションのいずれかです。
クエリがtempdbを使用するボリュームあたりX最大IOpsに構成されたリソースプールの場合、SSDであるかどうかに関係なく、単一の物理ディスク上の複数のボリュームにそのtempdbを分割し、単一のボリューム上のデータを使用すると、必要な粒度が得られる場合があります。いつものように、私はそれをテストします。