您还需要考虑客户希望为发布者提供哪些数据丢失要求,以及您是否已经在进行日志备份(我猜你是).

可以将数据库镜像设置为零数据丢失(只要镜像保持同步),但是根据事务日志生成速率和可用的网络带宽,等待事务记录在事务可以之前在镜像上加强对委托人的提交可能会减慢工作量.取决于您正在做什么样的交易(长或短)是否会对整体响应时间产生显着影响.

使用日志传送,它只是备份 – 复制 – 恢复,重复.因此,如果您已经在进行日志备份,那么您根本不会影响性能.如果您不习惯进行日志备份,则可能会遇到事务日志大小管理问题.

请注意,镜像需要完整的恢复模型,因此它可能会影响您的数据库维护,特别是如果您习惯使用BULK_LOGGED恢复模型.根据可用的网络带宽,这也可能导致日志大小管理问题.

两者都需要网络带宽,但方式不同.每次复制日志备份时,日志传送都会突发,数据库镜像更持久,显然取决于日志生成速率.我需要知道更多,以便能够判断任何一个所需的额外带宽量是否会影响复制流中的数据移动,从而影响那里的延迟.

使用日志传送时,您必须在发生故障时手动故障转移到日志传送辅助服务器,并且可能会丢失数据(自上次日志备份以来从主服务器复制的所有数据).然后你需要再次启动repl.

使用数据库镜像,您可以将其设置为自动进行故障转移,并且您可以专门将repl代理作业中的故障转移伙伴设置为在新主体(也是新发布者)上自动启动.棘手的是确保在本地群集故障转移有机会发生之前不会发生数据库镜像故障转移.您可以通过更改镜像伙伴超时值来执行此操作.我在http://www.sqlskills.com/BLOGS/PAUL/post/Search-Engine-QA-3-Database-mirroring-failover-types-and-partner-timeouts.aspx写了这篇博文.

我为Microsoft写了一份白皮书,描述了如何一起使用镜像和tranasactional复制：见http://www.sqlskills.com/BLOGS/PAUL/post/SQL-Server2008-New-whitepaper-on-combining-transactional-replication-and-database-mirroring.aspx.

在所有其他条件相同的情况下,我建议使用数据库镜像,因为它易于管理,可以减少数据流量.你可能还有一些我不知道的其他要求会阻止这种情况.

希望这可以帮助.