恢复时间目标

RTO 和RPO 大相径庭。RPO 与数据丢失相关，而RTO 的定义则是恢复速度。通常
认为RTO 比RPO 更重要，但这个观念往往并不正确。以下因素将影响RTO：
● 备用数据库的配置方式
● 没有备用数据库，需要使用备份
● 发生故障后同时转移数据库和应用程序
● 发生故障后是否同时转移中间层
● 员工的工作压力是否过大从而导致出错
错误观点：无法用Data Guard 获得低RTO
很多人认为无法使用Data Guard 获得低RTO，认定在发生故障后转移到Data Guard
备用数据库多则数小时，少则数分钟。事实并非如此。就像到不同系统的任何转移一样，
手动操作需要消耗时间。如果取消人工干预，在发生故障后迁移到Data Guard 备用数据
库在几秒钟内即可完成(见第8 章)。即使采用人工方式将Data Guard 备用数据库转变为
生产角色也仅需几分钟的时间。通常，客户端重新连接需要消耗更多时间。第10 章将介
绍如何使客户端自动进行故障转移。
我们都关注高可用性，这也是RTO 的一切。但是如果让系统可用，却失去所有数据，
将是一个超乎想象的大问题。这就是我们先讨论RPO 再讨论RTO 的原因。您就要通过
本章学习新知识，学习正确的思路以及如何计划和实施来应对不测事件。了解到所有这
些信息，就可以做出更好的决策。
那么您的RTO 预期是什么？每个人都想要零故障时间，也就是零RTO。
零RTO 并非不可能，这取决于看待故障的方式。一般而言，高可用性被视为尽快让
用户重新连接上，在集群环境中，只有连接到故障系统的用户才真正需要重新定位，此
操作由集群软件自行完成。使用集群中幸存系统的用户只会察觉到短暂的中断甚至察觉
不到。当然，这意味着您正在使用活动-活动(Active-Active)集群环境，如Oracle RAC。
如果使用冷故障转移集群(Cold Failover Cluster)，会经历到比Data Guard 更长的故障转移
时间。此外，无论主数据库的确切副本放在何处(隔壁的机房乃至全球范围)，Data Guard
都可以将高可用性扩展到那里。令人吃惊的是：影响RTO 的并非主数据库与备用数据库
之间的距离，而是将更改信息应用于备用数据库的速度，以及在需要之时实际执行故障
转移的速度。如前所述，距离会影响RPO，并不影响RTO。
了解到RPO 和RTO 需求(以及现实状况)后，就可以开始分析需要做出的Data Guard
决策了。此后，即可做好准备开始创建Data Guard 备用数据库。