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

相关推荐
努力成为AK大王1 小时前
并发编程的核心挑战、优化方案与核心知识点总结
java·开发语言·数据库
En^_^Joy2 小时前
Django开发:模板系统入门指南
数据库·django·sqlite
无关86883 小时前
Redis Bitmaps 用户签到系统设计方案
数据库·redis·缓存
江华森3 小时前
FastAPI 极速开发指南 — 从零到生产级 API 实战
数据库·fastapi
老纪4 小时前
Redis分布式锁进第九零篇
数据库·redis·分布式
haven-8524 小时前
MySQL事务ACID、隔离级别、MVCC、幻读解决
数据库·mysql
小高学习java4 小时前
事务的边界问题,如何判断数据回滚时机。
java·数据库·后端
迷枫7125 小时前
【无标题】
数据库
TDengine (老段)5 小时前
TDengine 扫描算子 — TableScan、TagScan 与下推优化
大数据·数据库·物联网·时序数据库·tdengine·涛思数据
放下华子我只抽RuiKe56 小时前
FastAPI 全栈后端(三):数据库与 ORM
前端·数据库·react.js·oracle·性能优化·前端框架·fastapi