它有多昂贵（CPU或内存明智）是有多个SQL Server 2005实例，而不是只有一个实例与前缀的数据库？
一个公司有三个应用程序提供者 他们每个将安装一个应用程序，他们每个需要两个或三个数据库。 他们都应该使用相同的实例，还是应该使用它自己的命名实例？
有一个或其他设置的强有力的理由？
在同一硬件上安装独立实例的唯一强有力的理由是，如果您有非常严格的安全隔离要求。 否则总是更好只有一个实例。 单个实例可以更好地优化所面临的负载的所有硬件资源。 多个实例不能相互通信，它们会覆盖内存，I / O和CPU负载，从而导致性能下降。
另外，单个实例更易于pipe理，监视和排除故障，而不是单独的实例。
如果您将SQL Server分解为单独的实例（或者也许是单独的虚拟机），则其优点是：
更好的资源限制。 SQL 2008的资源调控器是一个好的开始，但是仍然没有那么细致，特别是在限制IO方面。 使用虚拟服务器，您可以在虚拟机级别节制CPU，内存和IO，从而使您可以在较早版本的SQL Server上限制资源。
更轻松的性能升级和降级。 如果一个虚拟机需要扩展，就像它的应用程序突然变得越来越stream行一样，那么可以将其虚拟成更强大的机器，而不会中断。 另一方面，如果您使用多个实例，则需要花费大量时间和人力进行安装。
更灵活的中断窗口 – 如果你在一个操作系统（SQL的多个实例）上拥有所有的数据库，那么你必须做很多的协调来做Windows补丁。 如果它们分裂到不同的虚拟客户端上，那么只要每个guest虚拟机（及其匹配的数据库）最方便就可以进行修补。
更好的安全限制。 如果一个SQL Server遇到问题，并且需要第三方参与故障排除，则可以为他们提供操作系统级的权限，而不用担心他们会对安装在该框中的其他SQL Server执行什么操作。
应用程序兼容性问题较less。 某些应用程序仅与SQL Server的命名实例不兼容。
不过，并不是所有的独angular兽和彩虹。 多实例和/或虚拟服务器方法的一些缺点包括：
我与SQL Server专家Kevin Kline和Ron Talmage进行了关于整合与虚拟化的networking直播 。 但是，需要注册。
如果你正在寻找这条路线，我build议将实例分离到不同的硬件上，而不是在同一台机器上运行不同的实例。 如果每个实例都打算敲打，我宁愿所有锤子都敲一个实例，而不是在同一个盒子上敲三个实例，并增加额外的开销。
保持应用程序在不同的实例上。 这样提供者就看不到彼此的工作。 他们可能会更喜欢这种方式，因为他们会将他们的应用视为专有信息。 此外，他们可能需要不同的数据库设置（如整理）。
这样做的缺点是实例需要更多的内存。
如果任何应用程序的负载很重，则可能会将其放在自己的服务器上，或者至less是在物理上独立的磁盘卷上。 通常，单独的实例对于将数据库服务器的虚拟机分开是更可取的。