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,对性能影响可忽略不计。备份窗口完全避开业务高峰。

相关推荐
2401_878820472 小时前
Redis+Lua脚本实现全局令牌桶限流
数据库·redis·lua
Slow菜鸟3 小时前
Maven 仓库下载机制
java·数据库·maven
身如柳絮随风扬3 小时前
Redis 主从复制与哨兵机制详解:从原理到高可用实战
数据库·redis·缓存
冰小忆3 小时前
类变量在继承场景下的初始化规则是怎样的?
java·前端·数据库
YL200404263 小时前
MySQL-运维篇-主从复制
运维·数据库·mysql
Wzx1980123 小时前
MySQL什么时候索引失效反而提升效率?
数据库·mysql
AC赳赳老秦3 小时前
OpenClaw碎片时间利用:设置轻量化自动化任务,高效利用职场碎片时间
java·大数据·运维·服务器·数据库·自动化·openclaw
5201-3 小时前
向量数据库在 NPU 上的加速
数据库·pytorch·python
arbitrary193 小时前
自动化业务通报系统实现
大数据·数据库·python·jupyter