共计 4448 个字符，预计需要花费 12 分钟才能阅读完成。
简介： DBS Oracle 备份产品是阿里云自研的，联合阿里团体之前多年 Oracle 数据库的生产应用教训打造的云备份产品。它不仅提供了传统备份所提供的 Oracle 备份能力外，还实现了无入侵流式备份能力，同时和云以及泛滥云产品深度联合，在备份数据上提供数据湖剖析，并通过正本数据管理（CDM）技术提供 Oracle 秒级复原及 devops 能力。
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】中，如果 Primary 上的归档日志或者 Redo 长时间无奈同步到 Standby 上，此时可能可能失去满足【case1】的全量备份，既此时的备份是胜利的，也可能独立的复原，然而该全量备份没有蕴含主库最新的归档日志，导致咱们的备份不是最新无效的全量备份。
图 2 DataGuard 运行模式
因为 Primary 和 Standby 的运行原理不一样，在理论业务实现时，会遇到更多的稳定性问题，实现一致性全量备份须要解决如下几个问题：
- 如何避免 Standby 上的备份获取不到最新的 Primary 的 Redo 日志。
- 当 Primary 和 Standby 之间网络提早较大或者呈现网络分区，导致 Redo 传输太慢或者长时间无奈传输时，备份如何解决。
- 如何发现 Primary 或者 Standby 上的归档日志呈现了 gap，以及如何解决 gap。
- 如何防止备份的数据文件或者归档日志呈现损坏的数据块。
此外，在备份的过程中，您可能还要思考如下一些问题： - 定时的清理曾经备份过的归档日志。
- 避免备份数据中毒 / 歹意删除，确保任何时候都至多有一个可用的备份集用来做复原。
- 为了满足监管要求，实现备份数据的多地区存储。
DBS Oracle 备份
上述的两个举例展现了 Oracle 备份的复杂性和较高的技术难度。而对于以上提出的问题，DBS 联合阿里巴巴之前多年的 Oracle 生产和运维教训通过齐全自主研发，打造了 DBS Oracle 备份产品，帮忙阿里云客户不便低成本地备份和爱护 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 数据库，无需再做大量的数据拷贝。
快照 + 克隆：DBS 备份存储的疾速打快照的能力，帮忙用户打造不同工夫点的 Oracle 备份数据的黄金正本。基于这些黄金正本以及对黄金正本的秒级克隆能力，能够帮忙用户在十分短的工夫内（秒级）创立同一个工夫点的 Oracle 沙箱实例，不同沙箱实例之间无烦扰，帮忙用户实现 DevOps，比方在 Oracle 沙箱实例上实现业务变更验证，业务压测，业务公布测试等等。
图 4 DBS Oracle 正本复制治理
原文链接
本文为阿里云原创内容，未经容许不得转载。
