RMAN 增量备份(Incremental Backup)

1、概念

RMAN 增量备份是指 RMAN 只备份自上次备份以来发生过更改的数据块,而不是备份整个数据库的所有数据块。它是 Oracle 为解决大型数据库全量备份时间长、占用空间大的问题而设计的核心特性,也是现代企业级备份策略的基础。

简单类比:全库备份就像每周日把整个衣柜的衣服都洗一遍,而增量备份就像周一到周六只洗穿过的衣服。

2、适用场景

  • 大型数据库:数据量超过 1TB 的数据库,全量备份时间过长
  • 备份窗口有限:只能在夜间短时间内完成备份
  • 数据变化率低:每天数据变化量不超过 10% 的数据库
  • 需要频繁备份:要求每小时或每天多次备份的业务系统
  • 存储资源有限:备份存储空间紧张的环境

3、核心工作原理

3.1、基本机制

Oracle 数据库中的每个数据块都有一个系统更改号(SCN)。当执行增量备份时,RMAN 会扫描所有数据块,只备份那些 SCN 大于上次备份 SCN 的数据块。

3.2、关键技术:块更改跟踪(BCT)

这是 Oracle 10g 引入的革命性特性,彻底解决了增量备份需要扫描整个数据库的问题:

  • 启用后,Oracle 会在后台维护一个块更改跟踪文件
  • 记录所有自上次备份以来被修改过的数据块地址
  • 增量备份时,RMAN 直接读取这个文件,只扫描被修改过的数据块
  • 性能提升可达10-100 倍,特别是对于大型数据库

启动命令:

ALTER DATABASE ENABLE BLOCK CHANGE TRACKING

USING FILE '+DATA/bct.f' SIZE 10G AUTOEXTEND ON NEXT 1G;

4、增量备份级别与类型

4.1、备份级别

Oracle 支持 3 个级别的增量备份:

级别 含义 作用
0 级 备份所有数据块(与全库备份内容相同) 作为整个增量备份链的基线
1 级 备份自上次 0 级或 1 级备份以来更改的数据块 日常增量备份
2 级 备份自上次 0 级、1 级或 2 级备份以来更改的数据块 更细粒度的增量备份(很少使用)

重要区别:0 级增量备份与全库备份的内容完全相同,但只有 0 级增量备份才能作为增量备份链的基线,普通全库备份不能。

4.2、两种增量类型

12c + 版本支持两种增量备份类型:

类型 备份内容 优点 缺点
差异增量(Differential) 备份自上次任何级别备份以来更改的数据块 备份量最小,速度最快 恢复时需要应用所有增量备份
累积增量(Cumulative) 备份自上次 0 级备份以来所有更改的数据块 恢复时只需要应用最后一个累积增量 备份量较大,速度较慢

生产环境推荐:日常使用差异增量,每周日做 0 级备份,每周六做累积增量备份,平衡备份和恢复性能。

5、增量备份 vs 全库备份

对比维度 全库备份 增量备份
备份内容 所有数据块 仅更改的数据块
备份时间 长(与数据量成正比) 短(与数据变化量成正比)
占用空间 大(等于数据量) 小(通常为数据量的 1%-10%)
恢复时间 短(只需要恢复一个备份) 较长(需要恢复基线 + 所有增量)
依赖关系 无依赖,独立可用 依赖基线备份和之前的增量备份
适用场景 基线备份、数据库变更前后 日常备份、备份窗口有限的场景

6、增量备份命令

sql 复制代码
-- Level 0 基线备份
BACKUP INCREMENTAL LEVEL 0 DATABASE TAG 'INCR_L0';

-- Level 1 差异增量(默认)
BACKUP INCREMENTAL LEVEL 1 DATABASE TAG 'INCR_L1_DIFF';

-- Level 1 累积增量
BACKUP INCREMENTAL LEVEL 1 CUMULATIVE DATABASE TAG 'INCR_L1_CUM';

-- 启用 Block Change Tracking(强烈推荐)
ALTER DATABASE ENABLE BLOCK CHANGE TRACKING
  USING FILE '+DATA/ctfile.ctf' REUSE;

-- 查看 BCT 状态
SELECT * FROM v$block_change_tracking;

实例:启用 BCT 后增量备份时间从 4 小时降至 15 分钟

**S --- Situation(场景):**某物流企业核心数据库 3TB,每天执行 Level 1 差异增量备份,耗时约 4 小时,严重影响白天业务窗口。DBA 怀疑是未启用 BCT 导致全文件扫描。

**T --- Task(任务):**将增量备份时间控制在 30 分钟以内,不影响白天业务。

A --- Action(行动):

1、启用 Block Change Tracking:

ALTER DATABASE ENABLE BLOCK CHANGE TRACKING

USING FILE '+DATA/ctfile.ctf';

2、 验证 BCT 状态:SELECT status, filename FROM v$block_change_tracking;

3、重新执行增量备份测试;

4、监控 BCT 文件大小,确保不超过数据文件的 1/30000。

**R --- Result(结果):**增量备份时间从 4 小时降至 15 分钟,提升 16 倍。BCT 文件仅占 200MB,对性能影响可忽略不计。备份窗口完全避开业务高峰。

相关推荐
这个DBA有点耶1 小时前
信创场景下数据同步软件怎么选?对比开源CDC与原生闭环工具的结构性差异
数据库·mysql·架构
多客:duokelijie2 小时前
代练订单系统选型思路:跨品类游戏接入、订单分层管理、自动结算逻辑拆解!
数据库·mysql·微信小程序·前端框架·uni-app·php·持续部署
PingCAP2 小时前
平凯星辰上榜!2026 年胡润全球独角兽企业
数据库
PingCAP2 小时前
轨道交通 AFC 系统升级,平凯 Loop 把跨部门协同变成可追溯闭环
数据库
java_logo3 小时前
Docker 部署 CloudBeaver:轻松搭建网页数据库管理平台
数据库·docker·容器·数据库管理·dbeaver·轩辕镜像·cloudbeaver
李白客4 小时前
AI 数据库落地 NL2SQL:准确率卡在四成,问题在表注释不在模型
数据库
FluxDB4 小时前
FluxDB vs DBX vs DBeaver:GPUI、Tauri、Eclipse 三种技术栈实测
数据库·mysql
杨航 AI5 小时前
JEV的用法
java·前端·数据库
数据库小学妹5 小时前
MySQL分页结果不稳定:唯一键兜底与游标分页
数据库·mysql·dba