深度干货 | 如何借助云原生搞定Oracle备份快速恢复？

Oracle备份面临的挑战

在传统企业里，经常会用Oracle数据库去承载业务重要核心数据，同时Oracle针对不同的恢复场景提供了灵活多样的恢复操作方法，灵活的设计给备份和恢复带来了更多的复杂性，因此Oracle的备份管理相比于MySQL而言，对DBA在专业性上有更高的要求。

比如说，Oracle环境有多种：Standalone，Standalone+DataGuard，RAC，RAC+DataGuard，双机Oracle等，其中DataGuard还有多种运行模式，不同的Oracle环境的备份有一些细微差别，一个备份脚本很难同时满足这些场景，如果业务系统有多套Oracle环境，备份将会非常复杂，例如如何确保全量备份集总是有效的(可恢复的)等等。我们现在以一个具体的案例来说明这个问题：一致性全量备份。

• 一致性全量备份

何为一致性全量备份

在我们这篇文章里"一致性全量备份"的定义如下：

条件1：备份集中存在一个连续完整的归档日志序列，其开始SCN和结束SCN能够覆盖备份开始时的最小的数据文件checkpoint SCN和备份结束时最大数据文件SCN（只读和离线数据文件除外）。

条件2：备份集中包含恢复所用的全部数据文件，控制文件和参数文件。

条件3：备份集中包含尽可能新的归档日志。

条件1和2确保全量备份集的完整性，使得备份集可以独立的被恢复（恢复出一致的状态）。条件3可以确保全量备份集始终是最新的，不会出现“丢数据”的场景。满足上述条件的备份集叫做一致性全量备份集。

• 一致性全量备份的好处

一致性全量备份集有哪些好处呢？

• 方便转储：通常一个备份集是一个存储目录，简单的打包就可以转储到磁带，异地转储。
• 简化恢复：恢复时不依赖其他备份集，例如定时归档日志备份产生的备份集失效了不会影响全量备份集的有效性，一致性全量备份集总是可以独立的恢复。

图1 一致性全量备份

下面我们看一下在哪些场景中，我们有可能得不到一致性全量备份集，图1 中的case2-case5就是典型的非一致性全量备份。

在【case2】中缺失了部分的归档日志，违反了【条件1】中连续完整的归档日志序列这个条件。如 图2 所示，如果Primary和Standby之间网络出现了异常，此时主库可以正常地生成新的归档日志，但是Standby上将无法生成新的归档日志，当网络恢复后，DataGuard会从Primary上自动同步最新的归档日志，同时也会同步这部分缺失的归档日志，但是如果在执行全量备份期间，缺失的归档日志还没有被同步到Standby上，那么此时的全量备份集中的归档日志将会包含空洞，导致无法恢复。

在【case3】中归档日志的的最小SCN和数据文件最小SCN之间存在gap。图2 中的所有运行模式都有可能出现这个问题，例如用户在清理Standby上的归档日志时执行了delete force就会导致RMAN将那些还没有被应用的归档日志删除掉。

在【case4】中最新的归档日志SCN和最大的数据文件SCN存在gap。图2 中的【模式三】有可能出现这个问题，因为它是先同步redo到Standby的redo log file中，当主库执行Switch log之后，Standby上才会将redo log file归档到归档日志。如果Primary和Standby之间网络出现了问题，那么Primary依然能够正常生成归档日志，但是备库却不能执行redo log file的切换，不能生成新的归档日志，导致归档日志的SCN小于数据文件的最大SCN。相反，【模式一】和【模式二】则一定不会出现这种case，因为他们是先产生归档日志，然后再应用归档日志到数据文件，因此其归档日志最大SCN一定是大于等于数据文件最大SCN的。

在【case5】中备份集中丢失了部分的数据文件，例如，用户开启了（backup optimization）配置，此时RMAN会开启备份优化功能，如果某些文件或者归档日志被其他人备份过了，那么将不会再次备份。

图2 DataGuard运行模式

由于Primary和Standby的运行原理不一样，在实际业务实现时，会遇到更多的稳定性问题，实现一致性全量备份需要解决如下几个问题：

• 如何防止Standby上的备份获取不到最新的Primary的Redo日志。
• 当Primary和Standby之间网络延迟较大或者出现网络分区，导致Redo传输太慢或者长时间无法传输时，备份如何解决。
• 如何发现Primary或者Standby上的归档日志出现了gap，以及如何解决gap。
• 如何避免备份的数据文件或者归档日志出现损坏的数据块。
  此外，在备份的过程中，您可能还要考虑如下一些问题：
• 定时的清理已经备份过的归档日志。
• 防止备份数据中毒/恶意删除，确保任何时候都至少有一个可用的备份集用来做恢复。
• 为了满足监管要求，实现备份数据的多地域存储。

DBS Oracle 备份

图3 DBS Oracle备份示意图

如图3，DBS Oracle 备份与恢复采用 Oracle 内置的 RMAN 技术，实现 Oracle 数据库的热备份和恢复。备份管理员在 DBS控制台 简单配置备份策略，系统会根据用户配置的备份策略自动地创建数据备份任务，DBS系统向Oracle宿主机DBS备份客户端发送备份命令，DBS备份客户端执行RMAN备份脚本，流式无入侵地读取备份数据，并对数据执行压缩/加密等处理，最后将备份数据写入到云上加密的备份存储。整个备份过程不侵占用户本地磁盘空间和IO，对数据库完全无入侵。而对于数据恢复任务，备份管理员在 DBS控制台 点击发起恢复任务，此时DBS调度会向在Oracle宿主机上的 DBS备份客户端 发送恢复命令，DBS备份客户端 执行对应的RMAN脚本进行数据恢复。

基础能力

它在当前版本具备的技术特点如下：

• 完全自研：阿里巴巴之前是Oracle的使用大户，结合之前阿里集团对Oracle生产运维的经验完全自研打造Oracle备份恢复产品，以帮助用户实现低成本探索数据库及数据库备份国产化演进路径。
• 兼容的平台：支持Linux平台下的Oracle保护。
• 支持的数据库版本：10g/11g/12c/18c/19c。
• 支持的备份类型：全量备份和事务日志备份。
• 支持的备份粒度：实例。
• 备份对象：日志文件，控制文件，参数文件，数据文件。
• 加密情况：传输过程支持HTTPS加密，存储支持AES256，BYOK加密
• 支持的恢复粒度：Oracle单机恢复粒度包括：数据库实例（全库恢复）。
• 支持的恢复方式：支持原机异实例，异机原位置的指定任意时间点的恢复。
• RAC 恢复到单机：当 Oracle RAC 环境损坏时，支持将 Oracle RAC 恢复到单机环境中。
• 归档日志删除策略：基于备份成功次数，支持自动删除指定时间段内已备份的Oracle 归档日志，避免因归档日志过满影响数据库运行。
• 多通道：开启多通道备份可提高备份效率。用户可为根据数据文件和日志文件的存储量以及业务压力情况分别自定义通道数量，并行读取传输数据，从而充分利用磁盘 I/O。
• 数据库高级压缩：开启数据库高级压缩后，可以在备份过程中对备份数据进行压缩， 节省磁盘空间，提升传输效率。
• 无入侵：整个备份恢复过程，对源库无入侵，不依赖本地磁盘做中转。
  它还在持续迭代中，欢迎持续关注。

差异点

为什么要备份上云？

DBS Oracle备份是云技术和备份技术的结合，它不仅实现了传统的Oracle备份的能力（如上所述），而且在使用DBS云备份时：

• 天然实现6个9的备份存储稳定性：备份数据存储在阿里云OSS对象存储上，SLA达到6个9
• 天然实现同地域多机房容灾：备份数据按照多机房高可用容灾
• 低成本实现异地备份：
• 网络带宽：阿里云内部网络更高的带宽，更低的网络延迟，费用更低，可以实现更低的异地灾备RPO
• 恢复机器：相比于传统的数据备份保护方案，需要提前额外购买恢复用的机器资源。在DBS只需要在恢复时只需要按量付费通过DBS一键恢复到RDS，或者是通过DBS沙箱实例秒级拉齐临时恢复实例即可。

云备份带来更多

上云之后，DBS和云上众多云产品深度结合，提供了以下等能力，帮用户盘活沉寂的备份数据，降低用户TCO：

• 数据湖分析：相比于传统备份备份数据只能在恢复时使用而言，DBS与云上产品DLA（数据湖分析）深度结合，无需恢复则能提供逻辑备份数据的数据湖分析能力；
• 副本数据管理CDM：DBS与DAS、DMS，RDS等数据库产品深度整合，对 备份数据 提供 CDM(副本数据管理)能力，可以实现对物理备份秒级恢复，可以让用户基于备份数据实现devops及分析能力，大大提高数据资产的使用效率，降低TCO。

Oracle副本数据管理（CDM）

传统的数据恢复时间主要取决于数据的下载时间以及归档日志应用时间。恢复时间通常在小时级别。DBS Oracle 备份利用DBS存储的快照克隆挂载等技术，以及云实例的弹性生产能力，可以实现Oracle副本数据管理，让用户可以在几秒钟之内恢复出一个1TB的Oracle实例，帮助用户快速实现应急容灾，恢复演练，DevOps等需求。

为实现Oracle CDM能力，需要以下的技术能力，如图4：

全量备份+镜像复制：DBS用流式挂载备份的方式，结合RMAN Image Copy备份方式实现byte by byte的数据文件无入侵拷贝。在恢复时，通过流式挂载恢复的方式，可以直接用这份备份数据拉起Oracle数据库，无需再做大量的数据拷贝。

图4 DBS Oracle副本复制管理