我们刚刚从 SQL Server 2000 迁移到 SQL Server 2008。
我们在 2000 上使用自己的日志传送进行故障转移。对于 2008，我们需要决定使用自己的日志传送、内置日志传送还是复制。
我们的服务器上有许多数据库（400 多个）；有的小，有的大。
DB 服务器故障应该很少见，我们可以接受 15-30 分钟的数据丢失。更重要的是快速启动第二个 DB 服务器。
根据上述标准，我更喜欢使用日志传送还是复制？
如果进行日志传送，有没有简单的方法可以确保它在所有数据库上移动？
答案1
对于所有建议镜像的人来说 - 镜像 400 个数据库是不可能的。在达到 400 个之前，您将用尽工作线程，无论是在 32 位还是 64 位上。主数据库上每个数据库至少有 2 个工作线程，镜像数据库上每个数据库至少有 3 个工作线程。
这实际上与 DBA 的技能无关。这完全取决于业务或应用程序的 HA 要求是什么 - 这些是驱动因素，而不是 DBA 可以应对的因素。如果更复杂的解决方案必需的然后找一个DBA来处理这个问题必需的。因为 DBA 的技能而限制您的 HA 解决方案是毫无意义的。
数据库镜像也不是快速检测和快速故障转移 - 它完全取决于故障是什么、镜像伙伴超时是多少、SEND 和 REDO 队列是多少。镜像决定成为主服务器时，故障转移可能需要相当长的时间才能完成。我帮助许多客户实施镜像（在微软时，我拥有数据库镜像以及存储引擎的其余部分），自 2007 年离开以来。
忘记那么多数据库的镜像。
在我们给您建议之前，您需要回答一些基本问题：
- 您想要拥有整个数据库的冗余副本还是只拥有部分冗余副本？
- 您是否希望能够使用冗余副本？用于写入还是仅用于读取？
- 数据库的事务日志生成率是多少？
- 两个站点之间的网络带宽是多少？
日志传送可能是对您来说最简单的方式，无论是设置、监控，还是能够快速且在数据丢失限制内带来冗余副本。使用日志传送，您可以选择将冗余副本联机，而无需完成所有排队等待恢复的事务日志备份的恢复，但要接受数据丢失。
您还可以使用中间层路由技术实现简单的故障转移，甚至可以使用像 Windows NLB 一样简单的技术，使用 0/100 配置，或切换到 100/0。我还看到客户在服务器名称无法更改时使用 DNS 切换来实现故障转移。
使用复制时，您必须处理从发布数据库事务日志中收集事务、到达分发数据库，然后由分发代理推送/拉取到订阅数据库之间的不可预测的延迟。复制本身也可能会变得混乱，很难弄清楚和重置 - 日志传送非常简单。
鉴于您一直在使用自己的日志传送，我猜想 tran 日志生成率和网络带宽不是问题 - 我会坚持使用日志传送并避免复制。甚至不要考虑数据库镜像，因为它不适用于您的卷。
希望这能有所帮助 - 当我在 Microsoft 内部向 DBA 教授 HA 时，这实际上是两天的讨论内容 - 总结起来就是 5 分钟来回答这个问题。欢迎在评论中提出更具体的问题。
答案2
我们使用镜像进行最新的现场恢复。
对于通过 WAN 进行的异地备份（例如高延迟），我们使用内置的日志传送。
请注意，对于任一选项，您都必须为每个数据库进行设置，这对于 400 个数据库来说，将是一个巨大的麻烦。
您是否使用存储阵列（SAN 或 NAS）？最简单的方法似乎是通过存储阵列快照进行块级复制（使用适当的 SQL Server 静默插件）——这将自动捕获每个数据库。
答案3
以下是一些额外的想法：
我不认为复制是可行的方法。我通常将复制视为一种分发数据的方式，而不是 DR 解决方案。当尝试复制 400 个数据库时，您很可能会强调分发者和发布者角色，这最终可能会导致服务器瘫痪。此外，由于您需要为每个数据库设置发布者和订阅者，因此实施、管理和处理架构更改将是一场噩梦。
从日志传送的角度来看，是的，这是可以做到的，但是，由于您必须在每个数据库上实施日志传送，因此实施和管理将是一个挑战。如果发生故障，则必须手动将每个数据库联机并重新指向所有应用程序。根据您的工作负载，该解决方案很可能不会扩展到 400 个数据库。所以请测试。
处理如此多的数据库时，最好实施地理集群解决方案或使用某种形式的 SAN 复制并在卷或块级别工作。如果您没有 SAN，那么第三方软件（如 InMage 或 Doubletake）可能会奏效。
请记住，每种技术（例如日志传送、数据库镜像或复制）都会显著增加工作负载并对服务器性能产生负面影响，因此，在投入生产之前，请进行性能测试。
如果您决定使用日志传送，那么您可以编写包括故障转移在内的整个过程的脚本。
罗斯·米斯特里（Ross Mistry），SQL MVP
作者 - SQL Server 2008 管理与行政以及 Windows Server 2008 Unleashed
Twitter-@RossMistry
答案4
你的公司有多少钱？
如果它们齐平，并且需要移动全部然后使用双节点主动/被动群集，通过热 SAN 复制到另一个异地主动/被动群集即可解决问题 :)
如果没有，那么坚持使用日志传送 - 2008 Enterprise 为您提供了压缩日志备份的好处（以 CPU 为代价），并且从 2005 年起的所有版本的 SQL 都能够同时进行日志备份和完整备份（这在具有大量事务活动的 2000 个盒子上是有问题的）。