SQL Server 2008 の 3 つのインスタンスがあり、それぞれが異なるマシン上にあり、各インスタンスに複数のデータベースがあります。MDF ファイルと LDF ファイル用に、SAN に 2 つの個別の LUN があります。NDX ファイルと TempDB ファイルは、各マシンのローカル ドライブで実行されます。3 つのインスタンスがデータ ファイル用に同じボリュームを共有し、ログ ファイル用に別のボリュームを共有しても問題ありませんか?
SAN でシン プロビジョニングを行っていないため、複数のボリュームを作成してディスク容量を制限したくありません。データベースごとではなくても、インスタンスごとにボリューム (ドライブ文字) を作成するようにアドバイスされたためです。少なくともログとデータ ファイルを分割する必要があることは承知しています。インスタンスが実際のデータベース ファイルを共有することはなく、ドライブ上のスペースだけが共有されます。
どんな助けでも感謝します。
もちろん、答えは「場合による」です。ただし、それが何に依存するかについていくつかのヒントを与えることができます。
SQL Server インスタンスは、そのリソースに排他的にアクセスできることを "想定" しています。したがって、デフォルトで使用可能なすべての RAM がいっぱいになり、すべての CPU が使用され、最大のパフォーマンスを得るために I/O チャネルを飽和させようとします。これが、インスタンスが同じディスクに同時にアクセスしないようにするという一般的なアドバイスの理由です。
もう 1 つのことは、SQL Server は、シーケンシャル I/O アクセスがランダム I/O よりもはるかに高いスループットを提供することを「認識」しているため、多くのメカニズム (ログファイル編成、先読み、レイジー ライターなど) が機能していることです。ランダム I/O はできるだけ避けてください。
ここで、SQL Server の 3 つのインスタンスが 1 つのボリュームで同時にシーケンシャル I/O 要求を実行すると、ボリュームの観点からは、ランダム I/O 要求が再度発生し、パフォーマンスが低下します。
そうは言っても、I/O サブシステムが重大なボトルネックになっている場合にのみ問題になります。ログファイルのボリュームが十分に高速で、インスタンスからの連続した書き込みが混在しても問題が発生しない場合は、先に進みます。インスタンスに十分な RAM があり、ほとんどの場合、バッファ キャッシュからデータを読み取ることができる場合は、I/O サブシステムに多くの読み取りパフォーマンスは必要ありません。
いずれの場合も避けるべきことは、ログ ファイルまたはデータ ファイルのいずれかに対する複数の拡張ステップです。1 つのファイルシステム上の複数のファイルが拡大している場合、断片化が発生し、断片化により、単一のソースからのシーケンシャルな読み取りまたは書き込み要求が再びランダム I/O に変換される可能性があります。
SSD をディスクとして使用すると、全体像が再び変わります。これらにはまったく異なる要件と動作がありますが、SSD について何も言わなかったので、「従来の」ディスクベースのアレイまたは RAID 構成を使用していると仮定します。
簡単な要約: 状況が正しければ問題を回避できるかもしれませんが、SAN と SQL の両方の観点から、システムについて詳しく知らなければ評価するのは困難です。