我有一个连接到 SAN 的合理服务器，它将为多个相同的应用程序运行 SQL 服务器。一个应用程序能够读取另一个数据库不存在安全问题。
不幸的是，我们也在 32 位窗口中。
我认为最好在服务器上使用一个实例，启用 AWE 以便服务器实例可以使用我们拥有的几乎所有内存，然后在一个实例中运行每个数据库。
但是我在这件事上被IT部门的神否决了，所以我真的很想听听您对此的看法。从性能的角度来看，我认为一个 SQL 实例优于两个实例是不正确的吗？
我知道我们可以做一些故障转移的事情，但是在一个刀片上做这件事对我来说似乎有点矫枉过正。
SQL Server 2000 和 2005 Workgroup 和 Standard（32 位，我不确定 64 位）最多只能使用 2GB 内存，因此拥有两个实例将允许您使用全部 4GB。即使您在 x64 Windows 上运行 32 位 SQL 标准也是如此，事实上更是如此，因为您希望每 2GB 内存有一个实例。
原则上，使用具有两个数据库的单个实例比每个具有一个数据库的两个实例要快，尽管我不相信这是一个巨大的差异。拥有单独的实例对管理很有用。例如，如果您使用 SQL 登录，并且对于不同的数据库有不同的登录集，则使用单独的实例可以更容易地跟踪登录。
所以你的问题的答案是“这取决于”:-)
JR
Re Spence 的评论：32 位 Windows 上的 SQL Server Standard 最多可以使用 2GB 内存。如果使用 /3GB 开关，SQL Server Enterprise 可以使用 3GB。在具有 AWE 的 Windows 2003 Enterprise 上，至少可以使用 16GB 内存（可能更多），因此您可以通过运行多个 SQL Server 实例来从内存中获得更好的价值。
恐怕答案仍然是“视情况而定”。如果您有很多内存，即 8GB 或 16GB，那么您希望将最大的数据库放在单独的实例中，这样它们每个实例就可以有 2GB（或 3GB/3GB）。如果您只有 4GB，那么我可能会使用单个实例和 /3GB 开关，因为拥有两个实例所使用的少量额外内存不值得开销。
正如其他人在下面评论的那样，可能还有其他考虑因素。如果您同时引用两个数据库，例如在一个选择查询中，或者如果您从一个数据库插入另一个数据库，那么您希望它们在同一个实例中以提高速度。
32位是死胡同。
在 SQL2K5 中，诸如计划编译、计划大小本身以及因此 proc 缓存之类的内存消耗已显着增加超过 2k。如果您有很多用户（即大型组织和中层模拟），其他组件（如权限令牌缓存）也会增长。由于所有这些都无法从 AWE 中受益，因此您很难将繁忙的系统安装到 32 位内存空间中。如果您有复杂的查询和计划，聚合实例可能会导致非常高百分比的缓冲池被盗到这些缓存中，从而为数据留下一个小的缓冲池，从而导致已编译计划的持续缓存驱逐和低页面寿命预期。
另一方面，同一个盒子上的多个 SQL 实例有相互踩踏的趋势，从而相互触发内存压力。由于实例的内存管理器不相互通信，因此与单个实例相比，要找到平衡点要困难得多。此外，多个实例的处理器调度可能会遇到类似的问题，因为操作系统会在实例之间抢占 SQL 调度程序，从而导致 CPU 缓存垃圾。
恕我直言，我会说你们 IT 之神在这个问题上是错误的。只要在同一个实例中运行多个数据库不需要解决安全问题，这就是要走的路。多实例总是会引入一些开销，这将有效地给您的服务器带来次优性能。在管理方面，最好坚持一个实例。
多个实例的一个优点是它可以有效地扩展您的 tempdb - 如果您的应用程序大量使用 tempdb，并且您将每个实例的 tempdb 放在不同的主轴上，这可能会带来性能优势。
与往常一样，这取决于：数据库是否需要相互“对话”？
如果是针对同一个应用程序，您经常会遇到希望一个数据库读取或写入另一个数据库的情况。如果是这种情况，最好在一个实例上使用两个 DB。（没有链接服务器、共享登录、共享 tempdb 都是这里的优势。）
但是，如果这两个数据库是完全隔离的并且永远不会相互通信并且实际上彼此之间没有任何远程关系（即 SharePoint 和 SAP），那么两个实例可能更可取。（能够在不同的 Service Pack 级别运行，或限制一个实例使用的内存是我想到的两个优势。）
我们有一个应用程序，它使用封装了我们大部分业务逻辑的大型复杂存储过程。
我们的机器在 32 位窗口上运行。以前我们的后端由一个带有多个数据库的 sql 实例组成。
我们现在已经转移到在服务器上有多个实例的架构。
在我们在新框架上测试它的同一天，我们的应用程序的性能急剧下降，并且我们的大多数表单（尤其是那些从大型、复杂的存储过程中提取数据的表单）都超时了。