我有一个合理的服务器连接到一个SAN将运行SQL服务器的多个相同的应用程序。 一个应用程序能够读取其他数据库没有安全问题。
我们不幸的是在32位窗口中。
我认为最好在服务器上使用一个实例，启用AWE，以便服务器实例可以使用几乎所有的RAM，然后在一个实例中运行每个数据库。
不过，我被这个IT部门的神明推翻了，所以我很好奇听到你的想法。 从性能angular度来看，我认为SQL的一个实例比两个更好吗？
我知道我们可以做一些故障转移的东西，但是在一个刀片上做这件事似乎对我来说是过度的。
SQL Server 2000和2005 Workgroup和Standard（32位，我不确定64位）最多只能使用2GB内存，所以有两个实例可以让你使用全部4GB。 即使您在x64 Windows上运行32位SQL标准，情况也是如此，事实上，因为您希望每2GB内存创build一个实例。
原则上，在两个数据库中使用单个实例的速度比使用一个数据库的两个实例的速度要快，但我不相信这是一个巨大的差异。 分开的实例可能对pipe理有用。 例如，如果您使用SQLlogin，并且对于不同的数据库有不同的login集，则使用单独的实例可以更轻松地跟踪login。
所以你的问题的答案是“这取决于”:-)
JR
Re Spence评论：32位Windows上的SQL Server Standard最多可以使用2GB的内存。 如果使用/ 3GB开关，SQL Server Enterprise可以使用3GB。 在Windows 2003 Enterprise上，可以使用至less16GB的AWE内存（可能更多），以便通过运行多个SQL Server实例，从内存中获得更好的价值。
恐怕答案还是“视情况而定”。 如果你有大量的内存，比如8GB或者16GB，那么你需要将最大的数据库放在不同的实例中，这样每个内存就可以有2GB（或者3GB）。 如果你只有4GB，那么我可能会使用单个实例和/ 3GB开关，因为有两个实例使用的less量额外的内存将不值得的开销。
正如其他人在下面评论的，可以有其他的考虑。 如果同时引用两个数据库，例如在select查询中，或者如果从一个数据库插入到另一个数据库，则希望它们在相同的实例中提供速度。
32位是死路一条。
在SQL2K5中，计划编译，计划大小本身以及进程caching的内存消耗已经显着增加，超过了2k。 另外，像许可令牌caching这样的其他组件，如果你有很多用户（比如，大型组织和中间层模拟），它们往往会增长。 由于所有这些都不能从AWE中受益，所以您很难将繁忙系统安装到32位内存空间中。 如果您有复杂的查询和计划，则聚合这些实例可能会导致缓冲池的百分比非常高，这些caching会将一个小缓冲池留给数据，从而导致编译计划的caching逐渐消失，并导致页面预期寿命降低。
另一方面，同一个盒子上的多个SQL实例倾向于踩在彼此的脚趾上，引发彼此的内存压力。 由于实例的内存pipe理者之间没有交stream，所以与单一实例相比，find一个均衡要困难得多。 另外，多个实例的处理器调度也会遇到类似的问题，因为操作系统会抢占实例之间的SQL调度器，从而导致CPUcaching垃圾。
恕我直言，我会说你的这个神的IT是错误的。 只要没有安全问题需要解决在同一个实例中运行多个数据库的问题，那就是要走的路。 多实例总是会引入一些开销，这将有效地给服务器带来不理想的性能。 pipe理方面，坚持一个实例也更好。
多个实例的一个优点是可以有效地扩展tempdb – 如果您的应用程序大量使用tempdb，并且每个实例的tempdb位于不同的主轴上，这可能会带来性能上的好处。
一如既往，这取决于： 数据库是否需要互相“交谈”？
如果它是针对同一个应用程序的，那么当你想让一个数据库读取或写入另一个数据库的时候，你经常会遇到这样的情况。 如果是这样的话，一个实例中的两个DB是可取的。 （没有链接服务器，共享login，共享tempdb在这里都是有利的。）
但是，如果这两个数据库是完全隔离的，绝不会相互通信，事实上也没有任何相互之间（例如SharePoint和SAP）有任何关系，那么两个数据库可能更可取。 （能够以不同的Service Pack级别运行，或限制一个实例使用的内存是我头顶的两个优点。）
我们有一个应用程序使用大型和复杂的存储过程，封装了我们大部分的业务逻辑。
我们的机器在32位窗口上运行。 以前我们的后端由一个包含多个数据库的sql实例组成。
我们现在已经转移到了在服务器上有多个实例的架构。
我们的应用程序的性能在我们testing新框架的同一天大大降低，而且我们的大多数表单（特别是那些从庞大复杂的存储过程中提取数据的表单）超时。