我们刚从SQL Server 2000迁移到SQL Server 2008。
我们在2000年使用自己的日志传送进行故障转移。 对于2008年，我们需要决定使用我们自己的日志传送，内置日志传送或复制。
我们的服务器上有很多数据库（400+）; 有的小，有的大。
数据库服务器故障应该很less，我们可以接受15-30分钟的数据丢失。 更重要的是快速获得第二台数据库服务器。
根据上面的标准，我更喜欢日志传送还是复制？
如果日志传送，有没有一种简单的方法来确保它移动到所有数据库？
对于所有那些暗示镜像的人来说 – 将不可能镜像400个数据库。 无论是32位还是64位，在达到400之前，您都将无法使用工作线程。 主体上每个数据库至less有2个工作线程，镜像上每个数据库至less有3个工作线程。
这与DBA的技能真的没有任何关系。 这完全取决于医pipe局对业务或应用程序的要求是什么 – 这些是驱动因素，而不是数据库pipe理员能够应付的。 如果需要更复杂的解决scheme，则需要获得与之交易的DBA。 由于DBA的技能限制了您的高可用性解决scheme是无稽之谈。
数据库镜像也不是快速检测和快速故障切换，它完全取决于故障是什么，镜像伙伴超时是什么，SEND和REDO队列是什么。 对于一个故障转移完成一个镜子可能是相当长的一段时间，镜子决定做主要的。 我已经帮助许多客户实现镜像（在微软当我拥有数据库镜像以及其余的存储引擎时），并且从2007年开始。
忘记镜像的数量的数据库。
在我们提供build议之前，您需要回答一些基本问题：
对于您来说，日志传送可能是最简单的，无论是在设置，监控，还是只能在数据丢失限制范围内快速复制冗余副本。 通过日志传送，您可以select将冗余副本联机，而不必通过接受数据丢失来恢复排队恢复的所有事务日志备份。
您还可以使用中间层路由技术，甚至简单的Windows NLB（0/100configuration）或切换到100/0来实现简单的故障转移。 当服务器名称无法更改时，我也看到使用DNS切换的客户实现故障转移。
使用复制时，您必须处理从发布数据库事务日志中获取的事务之间的不可预知的延迟，点击分发数据库，然后由分发代理推送/拉入订阅数据库。 复制也可能会自行扭曲，并且很难找出并重置 – 日志传送非常简单。
考虑到你一直在使用自己的日志传送，我猜测传送速率和networking带宽不是问题 – 我会坚持日志传送，避免复制。 甚至不要考虑数据库镜像，因为它不适合你的音量。
希望这有助于 – 当我向微软的数据库pipe理员教授HA时，这真的是值得我们讨论的两天 – 解决了这个问题5分钟。 随时在评论中提供更具体的问题。
我们使用镜像进行最新的现场恢复。
对于通过WAN的异地备份（例如高延迟），我们使用内置的日志传送。
请注意，对于任何选项，您都必须设置PER DATABASE，对于400 DB，这将成为后面的巨大痛苦。
你使用存储arrays（SAN还是NAS）？ 最简单的方法似乎是通过存储arrays捕捉进行块级复制（使用适当的SQL Server quiesce插件） – 这将自动捕获每个数据库。
这里有一些额外的想法：
我不相信复制是要走的路。 我通常将复制视为分配数据的一种方式，而不是DR解决scheme。 当试图复制400个数据库时，您最有可能强调分销商和发布商angular色，这最终可能会使服务器瘫痪。 另外，如果您需要为每个数据库设置发布者和订阅者，则实现，pipe理和处理模式更改将是一场噩梦。
从日志传送的angular度来看，是的，可以这样做，然而，再次，实施和pipe理将是一个挑战，因为您必须在每个数据库上实施日志传送。 如果发生故障，则必须手动将每个数据库联机，并重新指定所有应用程序。 根据您的工作量，最有可能的解决scheme不会扩展到400个数据库。 所以请testing。
在处理这么多的数据库时，最好实施一个Geo-Cluster解决scheme或使用某种forms的SAN复制，并在卷或块级别上工作。 如果您没有SAN，那么第三方软件（如InMage或Doubletake）可能会有所斩获。
请记住，诸如日志传送，数据库镜像或复制等各种技术可能会显着增加工作负载，并对服务器性能产生负面影响，因此请在开始生产之前进行性能testing。
如果您决定使用日志传送，则可以编写包括故障转移在内的整个stream程。
SQL MVP的Ross Mistry
作者 – SQL Server 2008pipe理和pipe理和Windows Server 2008的释放
Twitter – @RossMistry
这很大程度上取决于您的DBA的技能。
如果您拥有熟练的DBA，那么如果您使用见证服务器进行configuration，镜像是最快速的故障切换的最安全select，那么“客户端”除了轻微的延迟之外不应该注意任何事情。 如果你的数据库pipe理员不太熟练，日志传送是一条可行的路线，但是它有一个更复杂的故障转移例程，这个例程涉及重放还没有被提交到主数据文件的事务并且没有被传送。 如果您希望丢失不超过15-30分钟的数据，那么镜像将是您的最佳select。
如果你只用2个服务器来完成这个任务，你应该把它设置为高安全模式，第三个可选的Witness服务器可以是一个SQL2008快速实例，所以你只花费最less的硬件成本，所以不要把它作为一个选项来排除。
我已经写了一篇关于如何在这个模式下镜像两个不是域成员的SQL 2005服务器的指南，并且可以在http://danmacs.blogspot.com/2009/05/database-mirroring-for-non-域ms.html
在这种情况下，故障切换是手动的（但速度很快），只有一个事务丢失的可能性（假设镜像运行正常）， 但连接到它的客户端需要手动移动（或通过DNS改变如果你正在做TCP / IP和不使用命名pipe道，命名pipe道可能会很好的工作，但我不能肯定地说）
贵公司有多less钱？
如果它们是齐平的，并且需要移动所有数据库，那么将具有温暖的SAN复制的双节点主动/被动群集复制到另一个异地主动/被动群集将会实现这个诀窍:)
如果没有，那么坚持使用日志传送 – 2008企业版为您提供压缩日志备份的好处（以cpu为代价），从2005年起SQL的所有版本都能够在完整备份的同时进行日志备份（这是有问题的在2000个具有大量交易活动的框中）。
第二个数据库纯粹是故障转移，还是希望能够用于MI报告。
你也看过镜像吗？
你有这个预算还是你想使用内部工具。 我以前使用过日志传送和复制，但是目前使用的Double Take已经非常棒了。
如果你有大量的时间投入创build系统手动login船舶400 +数据库，它的工作，我会坚持下去。 如果它拼凑在一起，并继续跑步（在那里）的痛苦，可能是时候换一个镜像了。
如果您尝试使用数据库镜像，我认为在100个数据库之前，您将耗尽工作线程，更不用说400+了。 看看这个 。
每个镜像数据库使用一对线程，SQL Server仅configuration为默认运行255个线程。 当你用完工作线程时，发生不幸的事情。 我运行了configuration了更multithreading（512，IIRC）的服务器，但似乎让MS非常紧张。 做一些令MS紧张的事情往往最终结果不好。
我认为你可以用400个日志传送的数据库，假设没有太多的日志stream量，并且你写了一些工具来帮助你设置和监视它们。 这些工具可以用tsql或类似powershell编写。
对于我来说，日志传送的真正问题是确保在另一台服务器上具有相同的login/包/链接服务器/等，确保相同的作业位于故障切换服务器上（但在您需要之前禁用以启用它们，并且需要一种启用和禁用它们的方式）， 返回到原始主站点，当日志序列由于任何原因而被破坏时如何重新build立日志传送，诸如此类的事情。 在进行部署时，很容易忘记做另一台服务器。
http://msdn.microsoft.com/en-us/library/ms366349(SQL.90).aspx
说10个镜像数据库是32位机器的最大数量。