1
Oracle数据库备份恢复十大问题和解决之道（一）.pdf
5墨值下载
Oracle数据库备份恢复十大问题和解决之道
（一）
近期正在国外休假，刚到国外的第二天晚上，由于时差还昏天黑地的，突然收到一位同事的
微信：“老罗，有没有关于数据库备份（RMAN）的最佳实践/规范之类的文档？”我马上发给了
他一份Oracle关于RMAN的十大最佳实践经验的官方文档，并回复他：“ 哈哈，我正准备写一篇关
于RMAN的十大问题和十大最佳实践的文章。”一周过去了，我时差已基本倒过来，也忙完了一些
其它客户的重要工作，于是今日就决定提笔酝酿已久的这篇文章了。
数据库备份恢复应该是自数据库管理软件诞生之日起就推出的最基础性技术。否则，若数
据库没有备份恢复功能，谁敢把自己的数据尤其是企业重要的商务数据存储在数据库之中？可
是，就是这样一个最传统、最基础性的技术领域，在我的数十年IT服务经历中，却发现各行各业
客户的几乎每套系统的备份恢复都存在一定问题。
“老罗你是不是太夸大其词，也太牛叉，甚至自以为是了？”且看我梳理的这十大问题，也
欢迎同行们对号入座，是不是被我不幸而言中了？反之，如果某位同仁发现某套系统的备份恢复
实施中没有我所描述的十大问题中的任何一个，请向我索赔精神损失费，哈哈。
1. 从原理开始
深奥无比的Oracle备份恢复技术
在数据库同行们的心目中，Oracle数据库软件博大精深，其备份恢复功能也是深奥无比，仅
仅是众多概念就够我们烧脑的了，诸如逻辑备份和物理备份；在线热备份和离线冷备份；数据库
归档模式备份和非归档模式备份；全量备份和增量备份；数据库级、表空间级和数据文件级备
份；数据库级、表空间级、数据文件级、数据块级恢复；完全恢复和不完全恢复；冗余备份数据
和过期备份数据管理和删除；备份恢复目录数据库管理 … …
曾经听到一位竞争对手同行的质疑：“你们Oracle的备份恢复技术太复杂了，仅RMAN备份恢
复指南文档就8、900页，你看我们数据库的备份恢复就几条命令，用户用起来多简单。”我第一
时间就回应道：“的确如此，所以你们的数据库只适合于最多几百GB的部门级数据库，每次进行
简单的全库备份和恢复就可以了。而我们Oracle数据库才是真正适合于TB级的企业级数据库产
品，必须是多种备份恢复策略和技术的精心设计，才能满足客户对备份恢复的全面需求。”
其实RMAN很简单
但是，本文将大道至简，回归备份恢复技术最简单的原理，并从这个原理角度去阐述备份恢
复的十大问题和相应的解决之道。本文将只讲述最重要的Oracle数据库物理备份恢复即RMAN技
术，其实RMAN的技术原理非常简单，本质上就是操作系统的文件级操作！甚至与复杂的数据库内
部逻辑尤其是与SQL逻辑无关，即与业务和应用没有直接关系，所以RMAN也叫做物理级备份恢复
技术。
了解Oracle数据库内部架构和从事过RMAN实施的同仁们都知道，Oracle软件虽然很高深，但
客户数据最终都是以各种文件形式（ASM文件、集群文件系统、普通文件系统、裸设备等）存储
在数据库服务器中，数据库的各种DDL、DML操作也是以日志文件形式（联机日志文件和归档日志
文件）存储在数据库服务器中。因此，无论是全库备份，还是增量备份，以及归档日志备份等操
作，都是对数据文件和日志文件进行备份操作，本质上就是文件复制和拷贝操作。例如，这就是
我20多年前为某银行最早实施的RMAN备份脚本：
backup incremental level 0 database format='/backup/FULL_%d_%t_%U' plus archivelog
delete all input tag=Weekly_Full_Backup;
backup incremental level 1 database format='/backup/DAILY_%d_%t_%U' plus
archivelog delete all input tag=Daily_Backup;
上述脚本分别是“全库备份+归档日志备份”和“1级增量备份+归档日志备份”，本质上就
是对数据文件和归档日志文件这两类文件在进行复制操作。
而RMAN恢复操作呢？无论是全库恢复，还是表空间恢复、数据文件恢复、数据块恢复等，也
无论是完全恢复还是不完全恢复，所有RMAN恢复命令都涉及到两个重要操作和步骤：先Restore，
然后Recover。Restore操作就是将全量备份数据从磁带库和磁盘重新加载到数据库之中，也就是
将全量备份数据重新复制和拷贝回数据库所在的ASM磁盘组、文件目录中，而Recover操作就是先
将增量备份数据加载回来，然后将相关的归档日志文件和联机日志文件中的日志项对被加载回
来的数据文件在数据块级别进行恢复操作。因此，无论是Restore的数据加载，还是日志文件的
Recover恢复操作，本质上也都是文件级物理操作。
因此也有人戏言，搞RMAN的人可以不懂数据库，尤其可以不懂SQL，但是若不懂操作系统、
不懂存储、不懂磁带库、不懂网络，肯定玩不好RMAN。也因此，本文即将展开的RMAN实施十大问
题其实都是文件级操作存在的问题。连文件级操作都有这么多问题，难道我们的大部分IT系统就
这么不堪？且听我一一道来。
2. Oracle官方的RMAN十大最佳实践经验
这就是我发给同事的Oracle关于RMAN的十大最佳实践经验的官方文档：《Top 10 Backup and
Recovery best practices. [ID 388422.1]》，本文仅将该官方文档的这十大最佳实践经验简
要罗列如下：(1)开启数据库坏块检查功能，检测物理存储故障；(2)实施快速增量备份技术，即
FIB技术；(3)对联机日志文件进行镜像，设置多份归档目录；(4)备份时开启check logical选
项，防止逻辑坏块，确保完整的备份数据；(5)测试备份数据；(6)权衡考虑每个Backup Piece包
含的数据文件数量；(7)采用并维护好Catalog数据库和控制文件；(8)注意控制文件备份恢复的
特殊性；(9)加强各种恢复预案的设计和演练；(10)在备份归档日志时，不要指定’delete all
input’。
上述十大最佳实践经验详细内容请各位看官去MOS查询ID 388422.1原文。应该说本人根据
经验总结的RMAN十大实施问题与Oracle公司官方的上述十大最佳实践经验有一定的契合，但并
非完全一致。本文后续将详细展开我所总结的十大问题，在与上述十大最佳实践经验重合时，再
展开官方文档的详细描述。
3. RMAN十大问题之一：全库备份时间太长
问题描述
先说一个故事：2020年底我去某省电力公司进行调研时，发现其一套重要生产系统达到了
50TB，但没有实施RMAN备份恢复方案，我问DBA原因何在，他坦言：“库太大了，备份时间太长，
备不出来，索性不备了。”同时我也了解到该库也没有容灾系统，于是我和他笑言：“你这不是
躺平吗？存储设备出了故障怎么办？”
这么重要的生产交易系统连备份都不实施在业内可能是极端情况，但是全库备份时间太长，
尤其是TB级以上库的全库备份时间动辄达到数小时乃至数十小时，则是业内非常普遍的现象。
问题后果
该问题带来什么不良影响呢？首先就是影响了白天的联机交易处理，备份操作通常应在夜
间完成，长达数小时乃至数十小时的全库备份操作，已经覆盖到白天的联机交易处理时段，与联
机交易操作形成了CPU、内存尤其是 I/O资源竞争，严重影响了白天的联机交易处理。
其次，全库备份时间太长，也导致数据库恢复时间延长。因为RMAN恢复操作不仅需要加载
（restore）所有或相关数据库文件，而且需要恢复（recover）全库备份期间的数小时乃至数十
小时的日志才能完成整个RMAN恢复操作。而 某些业务负载高的系统，数十小时的日志量可能达到
几个TB甚至更高，可能也需要几十小时的recover操作时间，我想基本满足不了客户的恢复时间
即RTO指标需求，很少有客户的IT系统能忍受几十小时的业务停顿。
解决之道
数据库备份包括全库备份不就是对整个数据库文件和日志文件进行复制拷贝吗？文件复制
如何进行优化？无外乎开源节流两个方面进行，所谓开源方面技术最典型的就是打开RMAN多个
备份通道、开启RAC多节点备份等，也就是同时进行多个文件的复制，也好比高速公路的收费站
of 9
5墨值下载
【版权声明】本文为墨天轮用户原创内容，转载时必须标注文档的来源（墨天轮），文档链接，文档作者等基本信息，否则作者和墨天轮有权追究责任。如果您发现墨天轮中有涉嫌抄袭或者侵权的内容，欢迎发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。
相关文档
评论