SQL Server インスタンス化: 複数のインスタンスまたはデータベースを使用する必要がありますか?

SQL Server インスタンス化: 複数のインスタンスまたはデータベースを使用する必要がありますか?

SAN に接続された適切なサーバーがあり、複数の同じアプリケーション用の SQL サーバーを実行する予定です。1 つのアプリケーションが別のデータベースを読み取ることができるため、セキュリティ上の問題はありません。

残念ながら、私たちも 32 ビット Windows を使用しています。

サーバー上で 1 つのインスタンスを使用し、AWE を有効にしてサーバー インスタンスが RAM のほぼすべてを使用できるようにしてから、各データベースを 1 つのインスタンスで実行する方がよいと私は考えています。

しかし、この件に関しては IT 部門の神々に却下されたので、皆さんの意見をぜひ聞きたいです。パフォーマンスの観点から、SQL のインスタンスが 1 つある方が 2 つあるよりも優れているというのは間違いでしょうか?

フェイルオーバー機能をいくつか実行できることはわかっていますが、それを 1 つのブレードで実行するのはやり過ぎのように思えます。

答え1

SQL Server 2000 および 2005 Workgroup および Standard (32 ビット、64 ビットについては不明) は最大 2 GB のメモリしか使用しないため、インスタンスを 2 つ持つことで 4 GB をすべて使用できます。これは、x64 Windows で 32 ビット SQL Standard を実行している場合でも当てはまります。実際、メモリ 2 GB ごとにインスタンスが必要になるため、さらに当てはまります。

原則として、2 つのデータベースを持つ 1 つのインスタンスを使用する方が、それぞれ 1 つのデータベースを持つ 2 つのインスタンスを使用するよりも高速ですが、それが大きな違いであるとは私には思えません。インスタンスを別々にすると、管理に役立ちます。たとえば、SQL ログインを使用し、異なるデータベースに異なるログイン セットがある場合、別々のインスタンスを使用すると、ログインを追跡しやすくなります。

したがって、あなたの質問に対する答えは「それは状況による」です :-)

JR

Spence のコメントについて: 32 ビット Windows 上の SQL Server Standard は、最大 2 GB のメモリを使用できます。SQL Server Enterprise は、/3GB スイッチを使用すると 3 GB を使用できます。AWE を備えた Windows 2003 Enterprise では、少なくとも 16 GB のメモリ (おそらくそれ以上) を使用できるため、SQL Server のインスタンスを複数実行することで、メモリをより有効に活用できます。

残念ながら、答えは依然として「場合による」です。8GB や 16GB など、大量のメモリがある場合、最大のデータベースを別々のインスタンスに配置して、それぞれ 2GB (または /3GB の場合は 3GB) になるようにします。4GB しかない場合は、インスタンスを 1 つだけ使用し、/3GB スイッチを使用することをお勧めします。インスタンスを 2 つ使用することで少量の追加メモリが使用されるため、オーバーヘッドに見合う価値はありません。

他の人が以下にコメントしているように、他の考慮事項もあります。たとえば、選択クエリで 2 つのデータベースを同時に参照する場合や、1 つのデータベースから別のデータベースに挿入する場合は、速度を上げるために同じインスタンスに配置する必要があります。

答え2

32 ビットは行き止まりです。

SQL2K5 では、プランのコンパイル、プランのサイズ自体、および proc キャッシュなどのメモリ消費が 2k を超えて大幅に増加しました。また、権限トークン キャッシュなどの他のコンポーネントも、ユーザー数が多い場合 (つまり、大規模な組織や中間層の偽装) は増加する傾向があります。これらすべてが AWE の恩恵を受けることができないため、ビジーなシステムを 32 ビットのメモリ空間に収めるのは困難です。複雑なクエリとプランがある場合、インスタンスを集約すると、バッファー プールの非常に高い割合がこれらのキャッシュに奪われ、データ用のバッファー プールが小さくなり、コンパイルされたプランのキャッシュが頻繁に削除され、ページの寿命の予測が低くなります。

一方、同じボックス上の複数の SQL インスタンスは、互いに干渉し合い、メモリ不足を引き起こす傾向があります。インスタンスのメモリ マネージャーは相互に通信しないため、単一のインスタンスに比べて均衡を保つのがはるかに困難です。また、複数のインスタンスのプロセッサ スケジューリングでも、OS がインスタンス間の SQL スケジューラーをプリエンプトするため、CPU キャッシュが破壊されるという同様の問題が発生する可能性があります。

答え3

私見ですが、IT の神々はこの点では間違っていると思います。同じインスタンスで複数のデータベースを実行することで対処すべきセキュリティ上の懸念がない限り、それが正しい方法です。複数のインスタンスは常にオーバーヘッドを発生させ、サーバーのパフォーマンスを実質的に最適化しません。管理の観点からも、1 つのインスタンスに固執する方がよいでしょう。

答え4

いつものように、それは状況によります:データベースが互いに「通信」する必要はありますか?

同じアプリケーションの場合、1 つのデータベースから他のデータベースを読み取ったり、他のデータベースに書き込んだりする必要がある場合がよくあります。その場合は、1 つのインスタンスに 2 つの DB がある方が望ましいです (リンク サーバー、共有ログイン、共有 tempdb がないことが、ここでの利点です)。

ただし、2 つのデータベースが完全に分離されていて、互いに通信することはなく、実際には互いにまったく関係がない場合 (SharePoint と SAP など) は、2 つのインスタンスを使用する方が望ましい場合があります。(異なるサービス パック レベルで実行できること、または 1 つのインスタンスで使用されるメモリを制限できることは、すぐに思いつく 2 つの利点です。)

関連情報