用SQL 2008 R2实现零和最低可能的RTO（小于15分钟）RPO的最佳方法是什么？

我们正在运行一个支付（EFT交易处理）应用程序，该应用程序正在全天候处理大量交易，目前正在研究将数据库复制到灾难恢复站点的更好方法。

我们目前和以前的战略包括使用DoubleTake和Redgate将数据复制到一个温暖的待命状态。

DoubleTake是支付软件供应商支持的解决scheme，但是他们在南非的（DoubleTake）支持非常差。我们有几个问题，根本无法解决，所以我们不得不放弃DoubleTake。

我们一直在使用Redgate手动读取主站点的数据（通过查询）并写入灾难恢复站点，但这是：

我们最近升级了整个系统在SQL 2008 R2 Enterprise上运行，这意味着我们应该考虑使用一些内置的复制function。

该服务器有两个相当大的数据库，其中包含高度易失事务数据和漂亮的静态configuration数据。

复制将通过WAN连接到单独的物理站点，并需要实现以下目标。

RPO：零损失 – 这是具有财务影响的交易数据，所以我们不能失去任何东西。 RTO：趋于零 – 业务取决于我们每分钟处理交易的能力，我们正在亏损

我已经看了一些其他的问题/答案，但没有一个完全符合我们的情况：

我目前的想法是，我们应该使用镜像，但我担心，对于RPO：0，我们将需要做延迟提交，这可能会影响主DB的性能，这是不是一个选项。

我们目前的DRstream程是：

换句话说，灾难恢复数据库需要尽快赶上初级，准备好作为新的主数据库进行处理。当我们准备好切换时，我们需要能够扭转这种情况。

有没有比镜像更好的select（我们也应该做日志传送），任何人都可以提出我们应该牢记的其他考虑因素？

你问的是正确的问题，并且能够很好地处理这个问题，不过酒吧的设置相当高。你正在寻找一个可能难以捉摸的东西，那就是五年前开发的技术。而且您已经在这个领域testing了两家供应商，他们还没有面对这个挑战。

规划未来。你现在拥有的是什么。您可以尝试重新devise现有技术或旧技术，但转向下一个版本可能是一个值得研究的选项。

我怀疑你用2008镜像描述的缺点是为什么微软在SQL Server 2012中引入了AlwaysOnfunction。2008镜像实际上是相当不错的，除非你有一个到镜像的高延迟连接并使用高安全模式。如果您的交易量很大，而且处理金钱，那么高安全性或高性能并不是一个容易的决定。

我自己的预测是，所谓的“云”提供商实际上将成为很多灾难恢复场景的天然契合点。他们拥有大多数公司无法承受的技术和专业知识，并且正在为可能的事情而努力。

asynchronous数据库镜像（高性能模式）
http://msdn.microsoft.com/en-us/library/ms187110%28v=sql.105%29.aspx

介绍SQL Server AlwaysOn
http://msdn.microsoft.com/en-us/sqlserver/gg490638

您也可以在存储级别进行复制。因此，您可以在应用程序层（数据库和存储级别）上获得复制。

由于此应用程序对于较低的RPO和RTO至关重要，因此您可以查找同步镜像，以便在主端发生增量时立即进行更新。

云是一个不错的select。它提供了很高的敏捷性，速度，现收现付模式，规模经济，全球覆盖等等，但由于这是与支付和银行相关的要求，您应该select私有云以提高安全性。另一方面，私有云将大大增加您的运营成本和总体成本。

所以你可能会考虑在软件和基础设施级别的复制技术。