我们正在规划一个服务器，它是集群 SQL2005 Enterprise 64 位，带有一个数据库，其中的表子集通过事务复制单向复制到位于不同数据中心的单个订阅者，以用于报告目的。分发器与发布器位于集群上。SAN 用于存储。
除了集群之外，客户还希望在发生 SAN 故障时，发布商数据库具有弹性。他们在同一个数据中心（不幸的是，从 DR 的角度来看）有第二个较小的 SAN（从性能角度来看）。这将有一个连接 SQL2005 32 位 Enterprise 的单个 32 位服务器。客户知道，如果发生 SAN 事件，他们将不再拥有集群或复制，并且性能水平会降低。
我正在考虑是否使用日志传送或数据库镜像来提供数据库 DR。我们使用 Quest LiteSpeed 进行备份，并且可以使用它来传送压缩的事务日志备份。
从性能和复制延迟的角度来看，这两种技术（镜像或日志传送）对发布者数据库的影响是否较小？
答案1
这得看情况。哈哈。
您还需要考虑客户对发布商的数据丢失要求，以及您是否已经进行了日志备份（我猜您正在进行）。
可以将数据库镜像设置为零数据丢失（只要镜像保持同步），但根据事务日志生成率和可用的网络带宽，等待日志记录在镜像上固化后再在主服务器上提交事务可能会降低工作负载。这取决于您正在执行的事务类型（长事务或短事务），这是否会对总体响应时间产生明显的影响。
使用日志传送，只需重复备份-复制-恢复。因此，如果您已经进行了日志备份，则不会对性能产生任何影响。如果您不习惯进行日志备份，则可能会遇到事务日志大小管理问题。
请注意，镜像需要 FULL 恢复模式，因此它可能会影响您的数据库维护，特别是如果您习惯使用 BULK_LOGGED 恢复模式。根据可用的网络带宽，这也可能导致日志大小管理问题。
两者都需要网络带宽，但方式不同。每次复制日志备份时，日志传送都会爆发，而数据库镜像则更持久，这显然又取决于日志生成率。我需要了解更多信息才能判断两者所需的额外带宽量是否会影响复制流中的数据移动，从而影响那里的延迟。
使用日志传送时，如果发生故障，您必须手动将故障转移到日志传送辅助服务器，并且可能会丢失数据（自上次从主服务器复制的日志备份以来的所有数据）。然后您需要再次启动 repl。
使用数据库镜像，您可以将其设置为自动故障转移，并且可以专门将 repl 代理作业中的故障转移伙伴设置为在新主体（也是新发布者）上自动启动。棘手之处在于确保数据库镜像故障转移不会在本地群集故障转移有机会发生之前发生。您可以通过更改镜像伙伴超时值来做到这一点。我在博客中谈到了这一点http://www.sqlskills.com/BLOGS/PAUL/post/Search-Engine-QA-3-Database-mirroring-failover-types-and-partner-timeouts.aspx。
我为微软写了一份白皮书，描述了如何一起使用镜像和事务复制：参见http://www.sqlskills.com/BLOGS/PAUL/post/SQL-Server2008-New-whitepaper-on-combining-transactional-replication-and-database-mirroring.aspx。
在其他条件相同的情况下，我建议使用数据库镜像，因为它易于管理，数据丢失的可能性也更小。不过，你可能还有其他一些我不知道的要求，可以防止这种情况发生。
希望这可以帮助。