我们正在计划一个集群式SQL2005企业版64位的服务器，其数据库的一部分表单通过事务复制单向复制到位于不同数据中心的单个用户，用于报告目的。 分销商与集群上的发布商位于同一位置。 SAN用于存储。
与群集一样，客户端在发生SAN故障时也希望为发布者数据库提供恢复能力。 从性能angular度来看，他们拥有第二个较小的SAN（不幸的是，从灾难恢复的angular度来看）同一个数据中心。 这将有一个单一的32位服务器与SQL2005 32位企业附加。 客户意识到，在发生SAN事件时，他们将不再具有集群或复制function，而且性能也会降低。
我在辩论是否使用日志传送或数据库镜像来提供数据库DR。 我们正在使用Quest LiteSpeed进行备份，并可以使用它来发送压缩事务日志备份。
从性能和复制延迟的angular度来看，两种技术（镜像或日志传送）中的任何一种对发布程序数据库的影响都较小？
这取决于。 哈哈。
您还需要考虑客户希望发布商的数据丢失要求，以及您是否已经在进行日志备份（我猜你是）。
可以将数据库镜像设置为零数据丢失（只要镜像保持同步），但取决于事务日志生成速率和可用的networking带宽，在事务处理之前等待日志logging在镜像上被硬化委托人可能会减慢工作量。 取决于你所做的事情（长或短）是否会对整体响应时间产生显着的影响。
随着日志传送，这只是备份复制恢复，重复。 所以如果你已经在做日志备份，那么你不会影响性能。 如果您不习惯进行日志备份，则可能会遇到事务日志大小pipe理问题。
请注意，镜像需要完整恢复模式，因此可能会影响数据库维护，尤其是在您习惯使用BULK_LOGGED恢复模式的情况下。 根据可用的networking带宽，这也可能导致日志大小pipe理问题。
两者都需要networking带宽，但方式不同。 每次日志备份被复制时，日志传送都是突发事件，数据库镜像更加持久，显然取决于日志生成速率。 我需要了解更多信息，以便能够判断两者所需的额外带宽的数量是否会影响复制stream中的数据移动，从而影响延迟。
使用日志传送时，如果发生故障，您必须手动故障转移到日志传送辅助服务器，并且存在数据丢失的可能性（自从上次日志备份以来从主服务器复制的所有数据）。 然后你需要再次启动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-和-database-mirroring.aspx 。
所有其他的事情是平等的，我build议数据库镜像，因为pipe理的简易性与潜在的数据丢失较less。 你可能有一些其他的要求，我不知道会阻止这个。
希望这可以帮助。