我不是DBA，所以这可能是一个愚蠢的问题，但我会问它。我们将我们的SQL Server从2000年升级到2005年，我们可能会使用数据库复制或数据库镜像。我们的DBA想要“多用途”备用服务器，这意味着他希望通过在备用服务器上运行其他数据库应用程序来增加我们的功能和容量，因为“无论如何它都会坐在那里”（他的话，不是我的） 。这是一个好主意吗？目前，我们的主应用程序服务器只使用一个包含50多个数据库的实例。据我了解，我们现在正在做什么以及我们的DBA提出的故障切换服务器是一个坏主意，因为所有这些数据库都共享内存，CPU和工作区域。如果一个应用程序开始表现不好，其他数据库可能会受到影响。多用途故障转移服务器？
有什么想法？
这真的是一个业务问题，需要回答？是一个缓慢的应用程序，如果你无法负担额外的硬件费用，那么应用程序就没有应用程序？
备用和镜像数据库可用于报告。如果你有足够的空间（即两个数据库都能舒服地在服务器上运行），使用它作为故障转移分区可以工作。
你会依赖这些额外的应用程序吗？他们在故障转移情况下运行在哪里？
你真的需要了解你的失败模式。
如果将其视为基础资源数学，那么除非您在故障场景中运行的资源能够处理整个预期负载，否则这通常并不合理。有时候是这样，但并非总是如此。在这种情况下，为了处理实际的负载，你可能需要另外一台服务器（比如RAID--也许你的负载至少需要5台服务器，但你有一个6台服务器，那么你需要一台备用服务器，在1以上失败）。有时候一个农场可能会退化，但有时他们只是呕吐而死。
而且在正常操作不正常的情况下，您经常会在事故级联导致级联问题时发生意外级联 - 例如，您的备份磁带正在忙于从备份恢复服务器（甚至是测试环境 - 没有真正的“失败”），现在您的sql server或exhcange服务器（或两者）不会备份并且日志已满。
数据库镜像不是我认为的方式，因为它仅在数据库级提供冗余。因此，您需要根据您提供的信息为最多50个数据库配置数据库镜像。有可能是因为如果一个DB在哪里可以全部失败，50可能会跟随，因为失败通常发生在硬件层面而不是特定的数据库。
这听起来像你应该使用SQL Server Clustering技术。您可以创建一个主动/主动群集来支持您的需求。
什么是主动/主动群集？
主动/主动SQL Server群集意味着SQL Server正在双向群集的两个节点上运行。每个SQL Server副本独立运行，用户可以看到两个不同的SQL Server。如果群集中的某个SQL Server应该失败，那么SQL Server的失败实例将故障转移到其余的服务器。这意味着那么SQL Server的两个实例都将在一台物理服务器上运行，而不是两台。
将此应用于您的方案
然后，您可以拆分SQL服务器，每个节点上的一个活动实例的两个实例之间的数据库。如果一个节点发生故障，另一个节点将收到松弛，反之亦然。
进一步阅读
An introduction to SQL Server Clustering
I suspect that you will find the following MSDN thread useful reading also
“这只是不管怎样都是坐在那里”
将坐在那里申请交易...
记下John Sansom的建议。请记住，主动/主动群集需要两个sql server许可证，故障转移群集/镜像只需要一个。
为大量数据库设置镜像可能会变成一大痛苦。您还需要任何作业/维护，以便通过WMI故障切换事件发出警报来实现。可能还有更多的想法会让事情变得复杂。
serverfault.com可能是这个问题的一个更好的地方 – 2009-06-02 16:24:59
当你说DB应用程序，你的意思是IIS或报告服务/ SSIS？ – Sam 2009-06-02 19:50:21