我正在使用SQL Server 2012 SP2的解决scheme，但没有使用AlwaysOn可用性组。 这是由于跨数据库事务，这不适用于这种情况。
注意：我们正在讲话时正在处理这个问题，但作为背景信息添加到我的问题中。
我们正在使用HP 3PAR StoreServ解决scheme，通过SAN获取站点到站点的同步复制。 这允许灾难恢复scheme跨站点工作，所以我们可以故障转移到我们的中学。
我关心的是0的RPO，因为有可能会丢失数据和发生损坏的场景。 例如，链接在站点之间被切断，然后主站点closures。
我的问题如下：
要么
如果一个链接被切断，SAN缓冲区块变化，直到连接恢复？
如果在TL日志写入和DR发生期间链接被切断，这是否意味着我们将有可能损坏的TL写入辅助站点，从而导致数据丢失？ 数据丢失仅仅是因为主要能够提交，但是次要的是不能同步的。
是否有RPO为零（SQL Server /内存/networking/ SAN / IO）的保证？
从HP 3PAR StorageServ白皮书： 用于要求容灾环境的复制解决scheme ，第6页：
对于同步复制解决scheme，解决scheme的RPO始终为零。 对于asynchronous复制解决scheme，RPO总是大于零。 asynchronous定期模式是asynchronous复制。 因此，在devise一个使用asynchronous定期复制的解决scheme时，RPO就成了一个问题。
SAN保证零容忍的RPO，那么在networking死亡的情况下，SAN不允许改变渗透到I / O？
更新：
我在上面的参考文献的第12页find了这个信息：
同步远距离拓扑
远程复制同步远程（SLD）拓扑是目前支持的唯一拓扑，允许将远程复制卷组中的卷从一个源StoreServarrays复制到两个不同的目标StoreServarrays。 它通过在两个StoreServarrays（“源”和“同步目标”数组）之间同步复制数据，同时通过周期性asynchronous模式将同一数据复制到第三个StoreServarrays（灾难恢复或“asynchronous目标”arrays）来完成此操作。 用户可以select以主动 – 主动的方式处理两个同步arrays，如果数据中心中的故障指示故障切换是必要的，并且在“同步目标”arrays上恢复操作，则在它们之间进行故障切换。 这提供了故障转移解决scheme，由于在同步arrays之间发生的复制的同步性质，所以提供等于零的RPO。
在故障转移到同步目标arrays时，该arrays和asynchronous目标arrays之间的被动asynchronous定期链接变为活动状态，并且任何已复制到同步目标但还没有到达同步目标arrays的数据都将从同步目标arrays到asynchronous目标，使asynchronous目标arrays保持最新，同步目标发生的最后一次写入。 然后操作继续在同步目标数据中心，并继续将数据复制到asynchronous目标arrays。
根据这些信息，您确实需要第三个端点参与asynchronous复制，以便在networking链接断开时，辅助站点将能够被通知更改。
我不能专门针对3PAR发表评论，但我对EMC Symmetrixarrays有很多经验。
我的build议是：find另一种方式。 同步复制是这些技术中看起来很棒的技术之一，在最佳环境下，但在现实世界中会造成巨大的痛苦。
它的工作方式是：
它是'RPO 0'的意思，如果它是在磁盘上它的远程站点。 大多数应用程序使用内存caching，这将在DR中丢失。 但是，它的价格很高：
您需要足够的总带宽到您的远程站点，您将永远有足够的服务复制要求 – 如果您不这样做，您的主要系统将遭受严重，因为磁盘延迟将大幅攀升。 如果你曾经饱和这个链接，你会受苦，你的主要服务可能会崩溃。
你将永远有一个延迟负担，你的performance将受到影响。
现在，这可能是“好”的。 根据我的经验，RPO0和“同步复制”通常只有当你有真正重要的事情时才被讨论。
直接回答你的问题：
Does the SAN deny data writes to the I/O until synchronisation has completed?
否 – 在进入同步模式之前，它会以asynchronous方式“赶上”。 这可能需要一段时间取决于bandwdith，直到它同步，你没有你的'0 RPO'。
If a link is severed, does the SAN buffer the block changes until the connection is restored?
取决于你的configuration。 一般来说，它会将链接挂起/恢复视为需要asynchronous再同步的事件。 当链接“出”时，您的RPO不再为零。 您可以在链接失败时“阻止”IO，但这可能会导致应用程序崩溃。
If a link is severed during a TL log write, and a DR occurs, doesn't this mean that we will have a potentially corrupt TL written to the secondary site, and therefore incur data loss? The data loss is only because the primary was able to commit, but the secondary was not able to synchronise.
否 – 同步意味着同步。 如果同步，磁盘上的IO也在远程。 不在磁盘上的任何IO都会丢失，所以您可能会丢失上次的超时日志。
Is RPO of zero ever a guarantee across the stack (SQL Server / Memory / Network / SAN / IO)?
RPO是恢复点目标。 如果你的目标是（真正）零，那么…你需要认真思考你的架构。 这是可以实现的，但是非常昂贵。
就个人而言，我会build议，而不是同步：
运行您的主数据存储asynchronous，并依靠您的日志提供“同步”位。 你的'RPO0' – 实际上说 – 只会是'你所承诺的积压'。 因此，NFS（CIFS？）安装一个远程驱动器，然后在networking和“本地”存储器上写入超时日志，并在几分钟内不同步数据库上重播。
无论如何，你将得到相同的恢复点 – 因为我非常怀疑你会想要使用未被logging的数据 – 而且你会这样做，而不需要昂贵的同步操作。