简介Oracle数据库RMAN备份与恢复.pdf是一份面向DBA与数据库运维人员的专业技术文献聚焦数据安全核心难题系统讲解如何利用RMAN保障企业数据库可靠运行。文档从物理备份与逻辑备份的基本概念入手剖析全备份、增量备份和差分备份的优缺点及适用场景并结合企业业务特点给出多级备份策略建议适用于需要掌握数据库备份恢复基础与排错思路的初中级DBA。压缩包内包含单个PDF文件仅55KB可离线阅读。该资源在CSDN已有952人学习浏览。内容不仅介绍RMAN跳过未使用数据块、二进制压缩等关键特性还涵盖改变归档模式、创建RMAN用户与恢复目录、注册目标数据库及实际备份恢复数据库文件等步骤配套讲解备份策略制定中的RTO/RPO评估、系统资源规划等要点能帮助读者快速搭建一套可落地的备份恢复框架。1. 先别急着写备份脚本Oracle 数据库 RMAN 备份与恢复的能力边界Oracle 数据库 RMAN 备份与恢复是应急时最依赖的一套命令集但它最反直觉的地方在于备份动作本身会成功恢复却经常失败。控制文件丢失、备份集被覆盖、归档日志缺失、目标端路径不一致任何一环断了restore都会停在原地。很多人手里拿着的是一本讲 RMAN 的 PDF 资料翻完一遍记住了BACKUP DATABASE和RECOVER DATABASE真到数据库起不来的时候反而不知道该先敲哪条命令。RMAN 的价值不在于“能备份”而在于它把备份、校验、恢复、清理做成了同一套元数据体系。它不只处理数据文件还能管理控制文件、参数文件、归档日志以及增量备份需要的变更跟踪信息。正因为它把备份信息写进了控制文件备份本身也需要被保护。这篇文章会把 RMAN 从最小可用命令讲到异机恢复、时间点恢复和日常校验按生产环境实际执行顺序展开。适合已经会写 SQL、但还没有系统梳理过 RMAN 的 DBA也适合那些备份脚本跑了一年、却没做过一次恢复演练的团队。2. 用最小命令跑通第一次 Oracle RMAN 全量备份2.1 备份前要确认的 3 个 Oracle 参数归档模式、FRA、控制文件自动备份RMAN 备份的第一个前置条件是数据库必须运行在归档模式下。非归档模式下只能做冷备份数据库 open 状态下执行BACKUP DATABASE会直接报错。确认方式很简单SQL SELECT log_mode FROM v$database; LOG_MODE ----------- ARCHIVELOG如果结果是NOARCHIVELOG需要先重启实例到 mount 状态再开启归档sqlplus / as sysdbaSQL SHUTDOWN IMMEDIATE; SQL STARTUP MOUNT; SQL ALTER DATABASE ARCHIVELOG; SQL ALTER DATABASE OPEN;第一个需要确认的参数是db_recovery_file_dest也就是快速恢复区 FRA。许多生产库把归档日志和 RMAN 备份都放在 FRA 里如果 FRA 大小设置过小日志切换一频繁就会出现ORA-19809: limit exceeded for recovery files数据库可能直接 hang 住。查看和调整SQL SHOW PARAMETER db_recovery_file_dest; SQL SHOW PARAMETER db_recovery_file_dest_size; SQL ALTER SYSTEM SET db_recovery_file_dest_size100G SCOPEBOTH;第二个要确认的是控制文件自动备份。RMAN 的备份元数据存在控制文件里可控制文件本身也是要被恢复的对象。如果没开自动备份每次BACKUP DATABASE后结构发生变化之前的控制文件备份就旧了。建议在 RMAN 里固定打开rman target /RMAN CONFIGURE CONTROLFILE AUTOBACKUP ON; RMAN CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO /backup/%F;%F是控制文件自动备份的专用格式包含 DBID恢复时 RMAN 能靠它自动找到对应备份。后面第 4 章恢复控制文件时依赖的就是这条配置。2.2 RMAN 备份集、备份片和通道先听懂这三件套很多人第一次看 RMAN 输出会被“backup set”“backup piece”搞混。备份集backup set是 RMAN 逻辑上的一次备份结果一个备份集里可以包含多个数据文件备份片backup piece才是真正写到磁盘上的物理文件。执行备份时用手工FORMAT指定的文件名是备份片的名字。通道channel则代表一个读写备份的会话。通道数决定了备份的并行度也会直接影响恢复时需要的资源。生产环境我一般会先做一次基础配置RMAN CONFIGURE DEVICE TYPE DISK PARALLELISM 2; RMAN CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT /backup/%d_%T_%s_%p.bkp;%d是数据库名%T是日期%s是备份集编号%p是备份片编号。这样命名的好处是备份文件能直接看出属于哪个库、哪一天、第几个备份集。并行度不建议一上来拉太高2 到 4 个通道对大多数单机环境足够通道多了会同时吃掉 IO 和 CPU备份期间业务 SQL 反而变慢。2.3 最小可用备份命令backup database plus archivelog 的字段含义第一次跑全备不需要写复杂的 run 块两条命令就能形成一个完整备份链RMAN BACKUP DATABASE PLUS ARCHIVELOG DELETE INPUT; RMAN LIST BACKUP SUMMARY;PLUS ARCHIVELOG的意思是备份数据文件前先把当前归档日志备走数据文件备份完再备份这期间新产生的归档。DELETE INPUT表示归档日志备份成功后从 FRA 里删除这些已备过的归档文件避免 FRA 被日志填满。LIST BACKUP SUMMARY用来确认备份集的状态是Aavailable而不是Xexpired。执行BACKUP DATABASE时RMAN 默认不会自动包含当前控制文件只有开了 2.1 节的CONTROLFILE AUTOBACKUP控制文件才会在每次备份结束时单独备份。如果没开并且备份时想手动带一份RMAN BACKUP DATABASE INCLUDE CURRENT CONTROLFILE PLUS ARCHIVELOG DELETE INPUT;注意INCLUDE CURRENT CONTROLFILE只对这一次备份生效它是补救手段不能替代CONTROLFILE AUTOBACKUP ON。3. 把全量备份升级为增量策略block change tracking 与保留策略3.1 全量、0 级、1 级差异、1 级累积选哪档最合适全量备份FULL每次扫描整个数据库恢复时只需一份备份加少量归档简单可靠但备份窗口和存储开销都大。增量备份分 0 级和 1 级0 级是增量备份的基底备份内容等同于全量但后续 1 级增量可以基于它做差异FULL不能被后续增量备份引用这一点经常被搞混。1 级又分两种差异增量默认备份上一次备份以来变更的块累积增量备份上一次 0 级以来变更的块。差异增量备份快、恢复慢累积增量备份慢、恢复快。实际生产库里最常见的组合是每周日凌晨 0 级周一到周六 1 级差异。RMAN BACKUP INCREMENTAL LEVEL 0 DATABASE PLUS ARCHIVELOG DELETE INPUT; RMAN BACKUP INCREMENTAL LEVEL 1 DATABASE PLUS ARCHIVELOG DELETE INPUT;这两种命令的区别只看LEVEL 0和LEVEL 1。0 级通常在周一凌晨执行1 级每天执行。配合PLUS ARCHIVELOG保证任何一次恢复都只需要“最近一次 0 级 之后所有 1 级 归档日志”而不是从几个月前的历史备份开始追。备份类型扫描范围备份耗时恢复耗时磁盘占用适用场景FULL全部数据块长短高小库、低频备份0 级增量全部数据块长短高增量策略的基底1 级差异上次 0/1 级以来变更块短中低每日常规备份1 级累积上次 0 级以来变更块中中中恢复时间敏感场景3.2 打开 block change tracking 给增量备份提速增量备份的默认行为是扫描整个数据文件找出发生变更的块。数据量一大即使每天只改几个 GB扫描耗时也接近全备。这时应该开启块变更跟踪Oracle 会在后台记录每个数据文件的变更位图增量备份只需读这个位图不用全文件扫描。SQL ALTER DATABASE ENABLE BLOCK CHANGE TRACKING; SQL SELECT status, filename FROM v$block_change_tracking;如果不指定USING FILEOracle 会把位图文件放到db_create_file_dest或 FRA 下。想手动指定路径也可以SQL ALTER DATABASE ENABLE BLOCK CHANGE TRACKING USING FILE /u01/app/oracle/oradata/ORCL/bct.ctf;开启后不需要重启。需要注意的是块变更跟踪文件本身不参与备份它只是一个加速索引损坏后最坏情况是增量备份退化为全文件扫描并不会导致备份失效。如果文件异常直接禁用再启用即可。3.3 用 CONFIGURE 把保留策略和自动清理写进控制文件备份只增不减FRA 迟早爆炸。保留策略有两种按冗余数量或按恢复窗口。RMAN CONFIGURE RETENTION POLICY TO REDUNDANCY 2; RMAN CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 7 DAYS;REDUNDANCY 2表示每个数据文件保留 2 份可用备份多出来的被标记为 obsoleteRECOVERY WINDOW OF 7 DAYS保证数据库能恢复到 7 天内的任意时间点。生产环境我更倾向用恢复窗口因为它能直接回答“能回退到哪天”这个问题。清理被标记为 obsolete 的备份标准动作是RMAN REPORT OBSOLETE; RMAN DELETE NOPROMPT OBSOLETE;REPORT OBSOLETE先看清单DELETE NOPROMPT OBSOLETE再确认删除。这里有个常见误区obsolete 和 expired 不是一回事。obsolete 是备份还在只是超出了保留策略expired 是控制文件里有记录但物理备份文件已经找不到。后者需要用CROSSCHECK先核对RMAN CROSSCHECK BACKUP; RMAN DELETE NOPROMPT EXPIRED;如果备份文件只是被手工移动了目录CROSSCHECK会把它标成 expired这时不要急着DELETE EXPIRED先确认文件是不是真的没了。物理文件还在只是路径变了应该用CATALOG START WITH /backup/重新登记。提示CONFIGURE的配置会持久化到目标库控制文件里换一台机器做异机恢复时这些配置不一定存在需要重新确认。4. 恢复才是目的同机还原、异机还原和时间点恢复4.1 先确认 RMAN 元数据还在list backup 与 catalog start with恢复动作开始前第一件事是确认 RMAN 还能读到备份元数据。连上目标库后执行RMAN LIST BACKUP SUMMARY;输出里能看到备份集编号、类型、完成时间和状态。如果这条命令报错或者返回空结果说明控制文件里的备份记录丢了常见于控制文件损坏后做了重建。这时只要有备份文件在磁盘上可以先把备份重新登记到控制文件RMAN CATALOG START WITH /backup/;CATALOG START WITH会把指定目录下所有可识别的备份文件重新加入控制文件。注意它会把目录下所有匹配文件都登记进来包括已经被清理的旧备份片所以执行完后最好跑一次CROSSCHECK BACKUP把找不到物理文件的记录标记出来再清理。对异机恢复来说这一步几乎是必经之路因为新库的控制文件里不可能有源库的备份记录。注意CATALOG START WITH无法找回备份里记录的数据文件路径它只登记“备份文件存在”真正恢复时还要靠第 4.3 节的路径映射。4.2 同机恢复数据文件与表空间的 restore/recover 命令最常见的恢复场景是单个数据文件损坏数据库还在 open 或 mount 状态。步骤是先 offline 再 restoreSQL ALTER DATABASE DATAFILE 5 OFFLINE;RMAN RESTORE DATAFILE 5; RMAN RECOVER DATAFILE 5; RMAN SQL ALTER DATABASE DATAFILE 5 ONLINE;RESTORE负责把备份中的数据文件放回原位RECOVER负责应用归档日志把文件前滚到当前时间点。如果只 restore 不 recover文件还是备份时刻的状态状态不一致打开数据库时必然报错。整库损坏时需要 mount 数据库后全量恢复RMAN STARTUP MOUNT; RMAN RESTORE DATABASE; RMAN RECOVER DATABASE; RMAN ALTER DATABASE OPEN;这里注意顺序restore 只是物理替换recover 才把数据库推到一个一致的时间点。看到ORA-01152: file was not restored from a sufficiently old backup这类错误基本就是 recover 时缺少归档日志说明备份链不完整。4.3 异机恢复SET NEWNAME 与 DB_NAME_FILE_CONVERT 的路径映射异机恢复最容易栽在路径上。源库的数据文件在/u01/app/oracle/oradata/ORCL/新机器可能装在/u02/oradata/orcl/直接RESTORE DATABASE会尝试把文件放回源路径如果目录不存在就报错。解决办法是逐文件指定新路径RMAN STARTUP NOMOUNT; RMAN SET DBID 1234567890; RMAN RESTORE CONTROLFILE FROM AUTOBACKUP; RMAN ALTER DATABASE MOUNT; RMAN CATALOG START WITH /backup/;RMAN RUN { SET NEWNAME FOR DATAFILE 1 TO /u02/oradata/orcl/system01.dbf; SET NEWNAME FOR DATAFILE 3 TO /u02/oradata/orcl/sysaux01.dbf; SET NEWNAME FOR DATAFILE 4 TO /u02/oradata/orcl/undotbs01.dbf; SET NEWNAME FOR DATAFILE 5 TO /u02/oradata/orcl/users01.dbf; RESTORE DATABASE; SWITCH DATAFILE ALL; RECOVER DATABASE; }SET NEWNAME只在当前 run 块内生效SWITCH DATAFILE ALL把控制文件里的记录指向新路径。如果新机器上实例名一致、目录布局也完全一致可以直接用DB_FILE_NAME_CONVERTSQL ALTER SYSTEM SET DB_FILE_NAME_CONVERT/u01/app/oracle/oradata/ORCL,/u02/oradata/orcl SCOPESPFILE;改完需要重启实例生效且只对后续创建的数据库对象自动转换路径RMAN 恢复时同样会读取这个参数。两种方式里SET NEWNAME SWITCH更直观因为恢复过程中能看到每个文件的最终去向。执行完RECOVER DATABASE后用ALTER DATABASE OPEN RESETLOGS打开数据库因为控制文件是从备份恢复的日志序列已经和源库不完全一致。4.4 误删数据的时间点恢复until time 与 RESETLOGS逻辑误操作比如TRUNCATE了一张大表归档日志还在可以用时间点恢复把整个库退回到误操作前。RMAN STARTUP MOUNT; RMAN RUN { SET UNTIL TIME TO_DATE(2025-06-10 10:30:00,YYYY-MM-DD HH24:MI:SS); RESTORE DATABASE; RECOVER DATABASE; } RMAN ALTER DATABASE OPEN RESETLOGS;SET UNTIL TIME之后的RESTORE会自动选择能恢复到该时间点的最近备份集合RECOVER应用归档日志直到目标时间点。时间点的选择很关键宁可选早一点不能选晚。如果误操作发生在 10:31:20恢复目标设为 10:31:00 是安全的设为 10:32:00 就把错误操作又恢复回来了。整库RESETLOGS会开启一个新的日志分支影响所有后续增量备份策略所以生产环境中更保守的做法是对单个表空间做 TSPITRRMAN RECOVER TABLESPACE users UNTIL TIME TO_DATE(2025-06-10 10:30:00,YYYY-MM-DD HH24:MI:SS) AUXILIARY DESTINATION /tmp/aux;RMAN 会自动在/tmp/aux创建辅助实例把users表空间恢复到目标时间点后再用数据泵等工具把数据导回生产库。整库其他表空间不受影响也不需要 resetlogs。5. 备份之后还要做的事校验、过期清理与恢复目录选择5.1 用 validate 与 backup validate 在备份时顺手查介质损坏备份成功不等于备份可用。如果数据文件里有坏块RESTORE过程可能到一半就失败。RMAN 提供两种校验手段RMAN VALIDATE DATABASE; RMAN BACKUP VALIDATE CHECK LOGICAL DATABASE;VALIDATE DATABASE读所有数据文件检查能否完整读出不产生备份文件BACKUP VALIDATE按备份的方式扫描文件CHECK LOGICAL额外做块级逻辑校验能发现物理损坏外的逻辑坏块。代价是扫描全库耗时不短所以不建议每次备份脚本里都跑一遍。我一般每周在备份窗口末尾执行一次RMAN BACKUP VALIDATE DATABASE CHECK LOGICAL;如果输出里没有RMAN-0开头的错误也没有ORA-01578块损坏这一周的备份基本可以认为在读取层面是安全的。注意VALIDATE只证明数据文件可读不证明备份集本身可恢复后者要靠第 6 章的RESTORE DATABASE PREVIEW。5.2 清理过期备份REPORT OBSOLETE、DELETE OBSOLETE 与 CROSSCHECK 的关系定期备份的环境里FRA 和磁盘空间会持续增长。清理动作的准确顺序是先REPORT OBSOLETE再DELETE OBSOLETE最后CROSSCHECK。前两个解决“超出保留策略的备份”后一个解决“控制文件记录和实际文件不一致”。RMAN REPORT OBSOLETE; RMAN DELETE NOPROMPT OBSOLETE; RMAN CROSSCHECK BACKUP; RMAN DELETE NOPROMPT EXPIRED;DELETE NOPROMPT OBSOLETE只清理旧备份不会动归档日志。想要连归档一起清理要用DELETE NOPROMPT ARCHIVELOG ALL COMPLETED BEFORE SYSDATE-7但这行命令需要和保留策略配合否则会把恢复窗口内的归档删掉。最容易出错的做法是脚本里直接删 FRA 目录下的文件这会让控制文件里的备份记录全部变成 expired下次恢复时LIST BACKUP看到一串 X实际物理文件可能已经没了。5.3 什么时候才需要建 RMAN Catalog 恢复目录RMAN 默认把备份元数据存在目标库控制文件里控制文件里相关记录的保留期由CONTROL_FILE_RECORD_KEEP_TIME决定默认 7 天。如果你每天备份、保留策略不超过这个周期用控制文件足够。但如果备份历史要保留一个月以上或者需要集中管理多个数据库的备份就应该用恢复目录。创建恢复目录的流程是把 catalog 放在一个独立数据库里不能让目标库自己兼任SQL CREATE USER rcat IDENTIFIED BY rcat_pass DEFAULT TABLESPACE rcat_ts QUOTA UNLIMITED ON rcat_ts; SQL GRANT RECOVERY_CATALOG_OWNER TO rcat;rman catalog rcat/rcat_passrcatdbRMAN CREATE CATALOG; RMAN REGISTER DATABASE;之后所有rman target / catalog ...的备份元数据会同时写入恢复目录和控制文件。缺点是恢复目录本身也要备份一旦 catalog 数据库故障恢复流程反而多一层依赖。小规模环境不建议一上来就建 catalog先把控制文件模式跑稳。5.4 常见恢复报错速查表实际运维里恢复失败的原因大多集中在下面几类错误代码典型场景处理方向ORA-19809FRA 空间不足归档无法写入增大db_recovery_file_dest_size清理过期备份和归档RMAN-06059期望的数据文件找不到对应备份检查备份集完整性CROSSCHECK后重新备份该文件ORA-01152restore 的备份太旧缺少中间归档补充归档日志或改用离故障点更近的增量备份ORA-01194recover 时需要的日志已被清理缩短备份周期扩大归档保留时间RMAN-20242catalog 认错了库备份集属于其他数据库重新REGISTER DATABASE或用SET DBID指定目标这类问题里RMAN-06059 最常见的原因不是备份没跑而是备份脚本把CONFIGURE RETENTION POLICY调得太短旧备份被自动清了真到恢复时才发现没有可用的全备基底。6. 最后一个技巧把恢复演练压缩成一条 REPAIR 命令恢复演练最大的阻力是“太麻烦”要准备一台新机器、要同步备份、要调整路径很多团队一年都练不了一次。RMAN 提供了一组不实际还原数据但能验证备份可恢复性的命令把它们拼进备份脚本等于每次备份后都自动做一次轻量演练。#!/bin/bash BACKUP_TAGPROD_L0_$(date %Y%m%d) rman target / log/backup/log/rman_${BACKUP_TAG}.log EOF BACKUP INCREMENTAL LEVEL 0 DATABASE PLUS ARCHIVELOG DELETE INPUT TAG $BACKUP_TAG; RESTORE DATABASE PREVIEW; RESTORE ARCHIVELOG FROM TIME SYSDATE-7 PREVIEW; EOF if grep -E RMAN-[0-9]|ORA-[0-9] /backup/log/rman_${BACKUP_TAG}.log; then echo RMAN backup or preview failed exit 1 fiRESTORE DATABASE PREVIEW不写任何数据文件它只读取控制文件和备份集元数据列出恢复时需要用到的全部备份文件、归档日志和起始时间点。如果某段数据文件缺失会直接报RMAN-06059不用真等恢复到一半才发现。RESTORE ARCHIVELOG ... PREVIEW同理专门验证归档日志是否齐全。脚本末尾的grep把 RMAN 错误码和 ORA 错误码捞出来保证备份成功但校验失败的场景也能被发现。这套组合命令的价值在于它验证的不是“备份是否完成”而是“从这些备份能否拼出完整的恢复链路”。数据文件、增量备份、归档日志三段任何一环断了PREVIEW阶段就会暴露。每月再做一次真正的异机恢复把历史备份恢复到一台临时实例用dbv file... verifyhigh抽查关键表空间的数据文件平时靠PREVIEW兜底演练时只做增量验证恢复能力就能持续保持在线。本文还有配套的精品资源点击获取