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