数据库容灾的设计与实现（五）

六、容灾方案的应用评估

上文中设计了油田数据级容灾系统，完成了基于Oracle Data Guard数据级容灾架构的设计和实施，实现了Broker Failover的FSFO切换技术、触发器提供不间断服务器端服务、客户端使用TAF实现透明故障转移的，完成了数据级容灾系统的建设。为了了解容灾是否满足生产业务的容灾需要，需对数据级容灾系统进行评估。

怎么做容灾系统的评估？当然是以容灾系统建设的目标的实现程度作为评价标准，数据级容灾系统的主要目标是数据安全、数据快速恢复的能力，以下的内容结合目标对我们的容灾系统进行评估。

（一）评价指标RTO及RPO

RTO，Recovery Time Objective，是指灾难发生后，从IT系统当机导致业务停顿之刻开始，到IT系统恢复至可以支持各部门运作，业务恢复运营之时，此两点之间的时间段称为RTO。一般而言，RTO时间越短，即意味要求在更短的时间内恢复至可使用状态。虽然从管理的角度而言，RTO时间越短越好，但是，这同时也意味着更多成本的投入，即可能需要购买更快的存储设备或高可用性软件。对于我们的数据级容灾系统来说，就是要把数据库恢复正常服务需要的时间，这个时间包括了数据库使用FSFO切换需要的时间，以及使用数据库的应用服务器或客户端恢复到能正常使用数据库的时间。

RPO，Recovery Point Objective，是指从系统和应用数据而言，要实现能够恢复至可以支持各部门业务运作，系统及生产数据应恢复到怎样的更新程度。这种更新程度可以是上一周的备份数据，也可以是上一次交易的实时数据。与RTO目标不同，RPO目标的确定不是依赖于企业业务规模，而是决定于企业业务的性质和业务操作依赖于数据的程度。对于我们的数据级容灾系统来来说，就是在灾难发生后，对数据库进行恢复后，保证我们的油气生产业务的连续性不受影响或者将影响降低到最小程度。结合油田的业务情况，油田开发生产业务对数据的实时性要求不高，少量的数据丢失不会对油气田的生产造成影响。

（二）RPO评估

数据安全的目标是在灾难发生时有备用的数据来保证我们的油气生产业务不受影响。数据安全的目标就是针对RPO的。

哪些事件可以定义为灾难呢？典型的灾难事件是自然灾难，如火灾、洪水、地震、飓风、龙卷风、台风等，还有其它如原先提供给业务运营所需的服务中断，如设备故障、软件错误、电信网络中断和电力故障等等。此外，人为的因素往往也会酿成大祸，如操作员错误、破坏、植入有害代码和恐怖袭击。

从以上可以看出，灾难大致分为两类，一类是客观的因素造成的，一类是人为因素造成。

1. 客观灾难下的数据安全评估

针对客观因素的灾难，我们的数据级容灾系统考虑了本地研究院和开发事业部机房的同城数据级容灾和相距200公里的轮南异地容灾，对油田开发的业务数据实现了非常安全的保护。在客观因素造成灾难之后，同城数据由于采用数据库复制技术的同步复制功能，通过没有任何数据损失，通过基于Broker Failover的FSFO灾难切换技术，实现数据库服务的快速恢复。在库尔勒基地的数据库因电力故障、自然灾难降而全部停运时，对轮南采用异步数据复制的Standby数据库通过Data guard的灾难切换failover恢复数据库服务，虽然可能有少量的数据丢失，对我们的油气生产业务基本没有什么影响，少量的数据损失也是在业务部门也在可接受的程度内。

在实际应用中，经过实际油田开发数据库服务的尖峰时刻为每秒产生500K的的REDO日志数据

综上所述，因客观灾难降临时，基于Data guard的同步复制可以数据更新程度到上一次个交易的级别，实现交易零数据丢失；异步复制在网络繁忙时和库尔勒基地数据库也只有5秒的数据同步差距，实际情况低于5秒，这对于油田现有的生产业务是没有影响的。

2. 人为因素灾难下的数据安全评估

针对人为因素的灾难，通过Oracle数据库内置的Flashback技术完成对数据库逻辑错误的快速恢复。也可以使用基于RMAN的数据备份对数据库进行恢复。

Oracle的Flashback技术从10G开始，支持数据库级、表级、行级及事务级闪回能够恢复几乎所有的数据库错误（除文件损坏、介质错误等问题之外）。

据库级别的闪回（Flashback Bataba.se )能够将整个数据库恢复到过去的时间点；表级闪回能够将数据表闪回到过去的时间点，或者对DROP掉的数据库进行闪回恢复；行级恢复闪回查询可以将表中的记录恢复到过去的时间点；通过事务级闪回，可以按照事务将数据库变更闪回。

（1）整个数据库闪回

当启动了Flashback Database功能后，数据库会定期将发生变化的数据块的前镜像写人闪回日志的日志文件中，在进行数据库闪回时，这些数据块可以被直接复制回来以满足数据库的恢复需求，同时Redo Log可以被应用以辅助数据恢复到更精确的时间点，从而极大的缩短了恢复时间。在传统的数据库恢复中，如果为了应对用户错误，那么通常需要进行基于时间点的不完全恢复，恢复的过程需要恢复数据文件、归档日志，再通过日志应用恢复到指定的时间点，这种恢复方式可能需要更长的恢复时间，而闪回数据库则可以避免文件恢复的过程，从而缩减恢复时间。初始化参数db_flashback_retention_target用于定义一个时间上限，用于设置数据库能够闪回的最大时间上限，单位是分钟。这个参数设置的只是一个期望值，确切的闪回时间取决于闪回区中保留的闪回数据。闪回区参数的设置我们在前文中已经描述，这里不再叙述。

（2）表级闪回

在生产环境中，可能用户会因为误操作而Drop掉了有用的数据表，从而导致了严重的数据库故障，在以前的版本中，恢复这样的错误一般需要通过备份进行不完全恢复。为了加快这类用户错误的恢复过程，Oracle 10g提供了 flashback drop的功能。 Oracle 10g的flashback drop功能，允许你从当前数据库中恢复一个被drop 了的对象，在执行drop操作时，现在Oracle不是真正删除它，而是将该对象自动将放入回收站（RecycleBin ), 对于一个对象的删除，Oracle其实仅仅就是进行了类似重命名操作。 所谓的回收站，是一个虚拟的容器，用于存放所有被删除的对象。在回收站中，被删除的对象将占用创建时的同样的空间，你甚至还可以对已经删除的表査询，也可以利用flashback功能来恢复它，这个就是flashback drop功能。

（3）行级恢复闪回查询

Oracle 10g对Oracle 9i中引人的闪回査询进行了增强，我们知道10g之前的闪回査询只能得到过去某个时间点上的数据版本，但是在当前时间和过去的某个时间点上，一个表中的数据 可能已经被变更或修改过多次，单一版本可能无法满足恢复的需要。 Oracle 10g通过Flashback Version Query允许我们对不同时间段内数据表的不同版本进行查询，查询可以反映不同时段内数据表的变更。根据变更可以说实现行级的闪回。

（4）事务级闪回

具备了 Flashback Version Query查询的基础，就可以进行基于Flashback Version Query的恢复，这就是 Flashback Transaction Query。

Flashback Transaction Query是一个诊断恢复工具，可以用于在事务级识别数据库的变更，与Flashback Versions Query类似，Flashback Transaction Query允许我们获取两个特定时间点之间的所有变更，更进一步的，flashback Transaction Query允许我们对于表进行基于事务的恢复。

（5）为了最大可能的减少用户错误的发生，在信息系统在建设和实施应充分控制好权限。程序员进行程序设计时使用测试数据库，比如通过Standby数据库复制一份作为测试库，这样可以避免主库造成影响。生产库的数据库录入人员，对录入权限进行严格的控制，比如油田开发数据库的录入用户，用户对当日数据具备修改权限，完成单日数据录入后由数据审核员审核后，当日数据就被加锁，失去修改数据的权限。如果发现历史数据录入错误需要修改，需要数据管理员解锁后才能修改，一次解锁只能修改一天的数据。通过这样的严格权限控制，可以保证数据库的安全

从以上可以看出，采用同步或异步的数据库复制技术结合数据库的闪回技术可以很好的满足油田开发的数据业务需要。可以得出这样一个结论，基于Data Guard数据级容灾系统可以充分保证数据库的安全，达到业务RPO目标，实现数据安全保护的目的。

（三）RTO评估

为了对RTO指标进行评估，对数据库进行故障切换测试，请示了油田相关领导，业务的尖峰时刻上午11点，对生产库进行了模拟故障切换，FSFO切换阈值设置为15秒的情况，实际总的切换时间为26秒。在这里主库和备库有千兆网络互连，备库采用实时应用REDO方式。

下图为Oracle的官方测试结果，总的时间不包含FSFO切换阈值的时间

Oracle测试环境：测试的数据库容量为100GB，当然故障切换时间不受数据库容量的影响，每台主机相互之间使用千兆网络互连，生产数据库每秒产生3 MB的 redo数据，上图中对数据库的单实例和多实例的RAC配置都进行了测试。测试的Data Guard配置中包括了故障切换到REDO应用的物理数据库和SQL应用的逻辑数据库。在以上条件下，总的切换时间不包括切换阈值为10到25秒之间。加上切换阈值15秒，可以计算出为25秒到35秒之间。主机性能也会影响这个结果，Oracle测试数据库的繁忙程度是油田开发数据库尖峰时刻的6倍，从官方的测试结果分析，油田开发数据库FSFO的切换时间最大不会超过30秒。

从上面的结果可以看出，从观察器检测到系统发生故障到自动执行切换命令，1分钟内完成（这里假定切换阈值15秒），期间已包括了数据库启动的时间，具有非常快速的恢复灾难的效率。而且修复损坏的主机数据库后，可以很容易的加入原来的容灾系统，恢复到原来的正常运行状态。

在实际工作中，调整监听文件中SDU设置有助于提高切换时间。

从客户端tnsnames.ora参数设置中可以看出，客户端在秒级就可以切换到新的主库上，综合考虑各种复杂因素，灾难切换的对用户端影响在分钟级，对数据业务连续性要求不高油田开发业务来说，可以很好的满足工作需要。

（四）数据级容灾系统应用情况

油田数据级容灾系统首先对开发事业部的油田开发数据库进行了部署。油田开发数据库是油田开发生产报表数据处理业务，包括塔里木油田油气藏工程月报、动态监测月报、油气生产综合日报、采油采气工艺报表处理系统的核心数据库。主库部署在油田中心机房的P590上，部署在开发事业部机房的P720上的备库和主库采用同步复制，部署在轮南的P560上的备库与主库采用异步数据复制，从而实现对开发数据库的数据保护。同时通过基于Data Guard Broker管理架构及FSFO技术实现对油田开发数据库服务的自动灾难切换。对油田开发数据库实施容灾后，经过反复测试评估后，确认完全可以满足整个油田的数据库容灾需要，在油田信息管理部的统一组织下，首先对整个油田的Oracle数据库进行了基于Data Guard及FSFO技术的本地容灾部署。

本章小结

本章分别从RPO/RTO对该数据级容灾系统进行了应用评估，经过模拟故障测试，实战演练的评估论证了该套数据级容灾系统完全能够满足数据库容灾的需要，且投入小、 产出高，在管理方面具有一定的方便性，很适合油田的全面部署推广。