简介面向Oracle数据库运维人员的RMAN全能备份脚本合集针对全量备份、增量备份与数据泵导出等高频场景提供即用Shell脚本可帮助DBA快速搭建自动化备份体系降低手工操作风险。压缩包共5个文件全部为shell脚本整体仅1KB。其中全备脚本基于RMAN执行database plus archivelog命令完整备份数据文件与控制文件0级与1级增量脚本分别对应incremental level 0和level 1可自由组合全备增量的备份策略数据泵脚本借助expdp实现逻辑备份便于迁移与恢复另附crontab定时脚本在Linux下按计划自动触发备份任务。目前已有132人学习下载适合需要规范化备份流程的数据库管理人员。这套脚本覆盖物理与逻辑备份配合RMAN validate校验和保留策略调整可显著提升数据安全性与灾难恢复效率是DBA日常运维的实用参考。1. Oracle RMAN全能备份脚本DBA 的风险控制里备份必须排在第一位凌晨两点的误删表、磁盘坏道、机房断电任何一个事故都能让 DBA 半夜爬起来翻备份。Oracle 官方工具 RMAN 功能完整但裸命令太多参数散落平时不固化成脚本真出事时根本来不及。所以 Oracle RMAN 全能备份脚本这件事本质不是“写一段 rman 命令”而是把备份策略、归档清理、保留窗口、恢复校验一起封装成 DBA 的日常操作规范。这套方案适合三类人刚接手别人数据库、对历史备份策略没有把握的运维负责多个实例、希望用统一脚本兜底的 DBA以及想从“能备份”升级到“能恢复”的团队。它解决的核心问题很具体备份文件别把磁盘写满归档日志别误删碰上故障时备份集能拉出来恢复。2. 备份脚本设计选型增量、保留与压缩不先定死后面全是坑2.1 增量备份的骨架Level 0、差异增量与累积增量怎么选RMAN 的完整备份概念是“incremental level 0”也就是把数据库里所有已使用的数据块写进备份集level 1 再分两种默认的差异增量和带 cumulative 关键字的累积增量。差异增量备份的是“自最近一次 level 0 或 level 1 以来发生变化”的块累积增量备份的是“自最近一次 level 0 以来发生变化”的块。恢复时如果走差异增量需要把一条链上所有 level 1 都找回来走累积增量只要最新的那一次 level 1 即可。选型上我一般这样定数据库写入量大、恢复窗口要求 7 到 14 天每周做一次 level 0中间再做一到两次 level 1 cumulative既能控制备份集体积又能让恢复时少拼增量链如果数据库很小或者 RAC 节点多、备份窗口短那直接每天都做 level 0 也简单但代价是备份集明显变大对磁盘空间和网络压力都要提前估算。命令层面最稳的写法是# 周日执行0 级全量基础 backup as compressed backupset incremental level 0 database plus archivelog delete input format /backup/rman/%d_%T_%s_%p_%u tag BK_L0; # 周三执行1 级累积减少恢复时需要拼接的增量数量 backup as compressed backupset incremental level 1 cumulative database plus archivelog delete input format /backup/rman/%d_%T_%s_%p_%u tag BK_L1;这里plus archivelog delete input是常见做法中最省心的组合它会在备份数据库前和备份结束后分别把这段时间产生的归档日志一起备份备份完成且校验通过后自动删除已经入备份集的输入归档避免归档日志越攒越多。我见过有的脚本把 database 备份和 archivelog 备份分开写然后漏了 delete input跑几天磁盘就报警。所谓“全能”第一步就是把这条组合命令用对。2.2 保留策略与删除边界recovery window、delete obsolete 与 delete archivelog 的配合保留策略决定 RMAN 认为哪些备份是“过时”的。常见的两种配置是冗余数和恢复窗口。configure retention policy to recovery window of 14 days;的意思是保证能把数据库恢复到 14 天内的任意时间点一旦某份备份不再参与这个窗口的恢复链RMAN 就把这批备份集标记为 obsolete。configure retention policy to redundancy 2;则更简单每个数据文件保留两份备份。delete obsolete删除的是被保留策略判定为过时的备份集和备份片但它不会去清理归档日志。所以脚本里必须再配一条针对归档日志的清理命令例如# 删除 7 天前已完成备份的归档日志注意是按日志的 completion_time 判断 delete noprompt archivelog until time sysdate - 7;这里就牵出很多 DBA 容易问的 from、until、before 区别。简单说在常见的 DELETE ARCHIVELOG 场景里until time按归档完成时间做过滤删除该时间点以前产生的归档保留最近 7 天from sequence n until sequence m按日志序列号划定范围适合想精确控制某一段线程日志的场景before这个词更常出现在list archivelog before time这类预览命令里用来判断哪些日志会落入删除范围。没见过老老实实写 delete archivelog before time 的脚本真遇到反而要警惕是不是版本兼容问题。稳妥做法是删之前先list archivelog until time sysdate - 7;看一遍再执行 delete。2.3 压缩、控制文件与快照不提前配置的 3 个隐形雷备份集压缩是控制磁盘占用最直接的手段。RMAN 里configure compression algorithm MEDIUM;可以在 BASIC 的基础上进一步压缩代价是备份期间消耗更多 CPU。对小库无所谓对大库要评估如果机器上还跑着应用CPU 占用飙高影响业务就别硬开高级压缩用默认 BASIC 或者把备份窗口挪到业务低谷。第二个雷是控制文件自动备份。configure controlfile autobackup on;能让 RMAN 在备份结束或结构变更后自动备份控制文件与 spfile这是恢复时定位备份集的钥匙。很多新手只备份 database不备份控制文件等控制文件损坏才意识到 RMAN 找不到 catalog恢复链条直接断掉。第三个雷是快照控制文件。RMAN 做备份时需要一个一致性快照控制文件默认位置往往在 ORACLE_HOME/dbs 下权限或空间都可能出问题。我习惯把它显式指到备份目录configure snapshot controlfile name to /backup/rman/snapcf_orcl.f;。这三件事不用天天改但必须在脚本第一次跑通之前配置好否则隔三差五冒出奇怪错误。3. 把脚本落到生产环境环境检查、完整脚本与参数说明3.1 写脚本前先做的环境检查实例、归档、空间、FRA 四查任何备份脚本跑之前先确认数据库和归档状态。第一步是确认实例能连、归档模式开着。常见做法是先在 SQL*Plus 里查两件事sqlplus -s / as sysdba EOF select name, open_mode from v\$database; select log_mode, flashback_on from v\$database; select round(sum(bytes)/1024/1024/1024,2) as arch_gb from v\$archived_log where archivedYES; EOF说明一下open_mode如果是 READ WRITE 表示数据库正常开放log_mode必须显示 ARCHIVELOG如果显示 NOARCHIVELOG备份脚本再“全能”也白搭因为归档日志根本不存在RMAN 无法做基于时间点的恢复。最后一条是把控制文件里所有归档日志记录占用的总空间拉出来作用是在清理前先心里有数避免误以为磁盘没空间、其实是历史归档记录膨胀。第二查是备份目录空间。df -h /backup确认目标盘剩余空间最好留出一次全量备份 2 到 3 倍的余量。如果数据库开启了闪回恢复区还要看db_recovery_file_dest指向哪里、大小边界是多少这个在第 4 章会有专门说明。四查做完再跑备份脚本本身只负责执行不做运行时判断责任边界清楚。3.2 生产可用的全能备份脚本周日全量、平日增量加归档清理下面是我在生产环境里最常用的一套脚本骨架Linux 下直接用。它会自动判断周日做 level 0其余日期做 level 1并在每次备份后完成 crosscheck 和清理。#!/usr/bin/env bash # Oracle RMAN 全能备份脚本周日 0 级平日 1 级自动备份归档并清理 # 适用版本Oracle 11gR2 / 12c / 19cnocatalog 模式Linux export ORACLE_SIDorcl export ORACLE_HOME/u01/app/oracle/product/19.0.0/dbhome_1 export PATH$ORACLE_HOME/bin:$PATH BK_DIR/backup/rman LOG_DIR/backup/log DOW$(date %u) if [ $DOW -eq 7 ]; then LEVEL0 else LEVEL1 fi TS$(date %Y%m%d_%H%M%S) RMAN_LOG$LOG_DIR/rman_${TS}_L${LEVEL}.log mkdir -p $BK_DIR $LOG_DIR rman target / log $RMAN_LOG EOF configure controlfile autobackup on; configure controlfile autobackup format for device type disk to $BK_DIR/cf_%F; configure snapshot controlfile name to $BK_DIR/snapcf_orcl.f; configure retention policy to recovery window of 14 days; configure device type disk parallelism 2; backup as compressed backupset incremental level $LEVEL database plus archivelog delete input format $BK_DIR/%d_%T_%s_%p_%u tag BK_L${LEVEL}_%T; crosscheck backup; crosscheck archivelog all; delete noprompt expired backup; delete noprompt expired archivelog all; delete noprompt obsolete; EOF RC$? if [ $RC -eq 0 ]; then echo $(date %F %T) RMAN backup OK LEVEL$LEVEL $LOG_DIR/backup_status.log else echo $(date %F %T) RMAN backup FAILED RC$RC $LOG_DIR/backup_status.log exit 1 fi这段脚本的每个部分都有明确作用。DOW判断周几是让脚本自己去定级别省得周一到周五分别挂 crontabrman target / log里带log参数把每次执行过程单独存档排查问题时有据可查。脚本里的configure命令推荐第一次跑通后就保留因为它们会把配置持久化到目标库重复执行不会产生破坏性影响只是每次备份开头多写几条配置记录。如果你希望减少干扰跑通后可以把 configure 段注释掉只留 backup 和清理命令。加进 crontab 时建议错开业务高峰比如周日凌晨 1:30、平时凌晨 1:00 各执行一次30 1 * * 7 /u01/scripts/rman_backup.sh /u01/scripts/backup_shell.log 21 0 1 * * 1-6 /u01/scripts/rman_backup.sh /u01/scripts/backup_shell.log 21注意 crontab 里要用绝对路径脚本开头不要把环境变量省掉否则定时任务经常环境变量加载不到这就是第 4 章会专门讲的坑。3.3 关键参数逐项说明format 变量、parallelism、恢复窗口和 exit codeformat字符串里%d是数据库名%T是年月日%s是备份集编号%p是备份片编号%u是 RMAN 自动生成的唯一标识。这样命名出来的文件既能按日期归档又能保证重名概率极低。控制文件自动备份的格式必须是%FRMAN 要求这个格式才便于它自动计算文件名不能自作主张改成%U。parallelism 2表示备份并发开两个通道。并发通道不是越多越好它受磁盘 IO 和 CPU 共同限制。单块机械盘上开 4 通道反而会让头频繁寻道如果是 PCIe SSD 或 ASM 存储开到 CPU 核数的四分之一到一半通常比较合理。小库保守起见就用默认并行度 1先跑一次全量看备份时长再决定要不要加通道。recovery window of 14 days是保留策略它保证能恢复到 14 天内任意时刻。这里有个常见误解不是“保留最近 14 天的备份文件”而是“保留足以恢复到 14 天内任意时刻的备份集合”。所以如果 0 级备份在 17 天前RMAN 仍可能保留它因为它是恢复 14 天前某个时间点所必需的基础。脚本最后的RC$?是 bash 捕获 rman 命令退出码。RMAN 本身有backup完成后的校验逻辑但只有退出码能被 cron 感知。生产环境里我会把退出码写进独立的状态日志再配合监控把非零退出码及时告警出来——这一步是“全能备份脚本”和“能看的备份脚本”的分界线。4. 生产运维避坑备份“老是满”、归档删除不生效与恢复失败的排查记录4.1 备份文件把磁盘写满归档日志只备不删的连锁反应现象备份脚本每天正常执行日志里也显示 success但过了一两周磁盘使用率持续上涨最后备份失败oracle 数据库开始报空间不足。原因最常出现在“数据库备份”和“归档日志备份”分开写的脚本里。常见写法是backup database format ...;后面跟backup archivelog all;却没有delete input也没有单独的归档清理策略。归档日志只会越积越多把备份目录或者闪回恢复区撑满。解决统一改成plus archivelog delete input让 RMAN 在备份完归档后立刻删除已入备份集的日志同时保留delete obsolete。如果已经满了先用list archivelog until time sysdate - 3;确认哪些归档可以安全删再执行delete noprompt archivelog until time sysdate - 3;把空间先释放出来再补一轮全量备份重建基础。4.2 归档删除的边界误用from、until、before 到底差在哪现象有人在清理脚本里写delete archivelog before time sysdate-7执行后要么报语法错要么删的数量和预期完全不符还有人写delete archivelog until time sysdate-7后把最近 7 天的归档也删了导致增量链断裂。原因对 RMAN 删除语义不熟。until time按归档 completion_time 判断并删除该时间之前的日志from sequence n until sequence m按日志序列号区间删除before在 RMAN 里更多出现在list archivelog before time这类预览命令中直接挪到 delete 里使用很容易踩版本差异。边界条件没搞清就动手是这类问题的主因。解决清理前先预览。执行list archivelog until time sysdate - 7;看输出里的 FIRST_TIME / COMPLETION_TIME确认范围后再 delete。删除时带noprompt前务必确认已看完预览结果。对于跨线程的 RAC 环境还要注意归档删除不能只按时间不看 thread最好按until time加上日志序列双重过滤。4.3 闪回恢复区被写爆ORA-19809 与 db_recovery_file_dest_size现象早上一看告警日志出现ORA-19809: limit exceeded for recovery files或ORA-19815: WARNING db_recovery_file_dest_size数据库进入受限状态备份和归档同时失败。原因开启闪回恢复区后备份集、归档日志、控制文件自动备份全都往db_recovery_file_dest里写而db_recovery_file_dest_size默认值没根据备份集大小调整。RMAN 不会自动清理旧的归档日志只靠保留策略处理备份集闪回区越塞越满。解决先看当前值和实际占用show parameter db_recovery_file_dest; select name, round(space_used/1024/1024/1024,2) gb from v$recovery_file_dest;然后扩容或改策略。把db_recovery_file_dest_size调到全量备份加近期归档日志的 1.5 到 2 倍比如 20Galter system set db_recovery_file_dest_size20G scopeboth;。同时也要把脚本里的归档清理真的执行起来。如果闪回区本身放在系统盘建议把db_recovery_file_dest改到独立大分区避免系统盘被写满导致实例崩溃。4.4 定时任务里备份失败、手动却成功环境变量没带到 cron现象手动在终端执行/u01/scripts/rman_backup.sh一切正常但 crontab 里一到点就失败状态日志里 RC 非零RMAN 日志报无法连接目标实例或者找不到 sqlplus。原因cron 执行 shell 时不会自动加载 oracle 用户的环境变量导致ORACLE_SID、ORACLE_HOME为空rman 或 sqlplus 要么命令找不到要么连不上目标库。这是 Oracle 备份脚本最经典的翻车点。解决脚本第一行加export ORACLE_SIDorcl和export ORACLE_HOME...并显式把$ORACLE_HOME/bin加进 PATH。在脚本里用绝对路径调用 rman写/u01/app/oracle/product/19.0.0/dbhome_1/bin/rman而不是裸写rman。如果用的是 Linux 的su - oracle -c方式调度则先确认 oracle 用户的.bash_profile里有完整环境再执行脚本。5. 进阶让备份“可验证”——定期恢复演练与自动报告小技巧备份脚本跑得再顺也不能证明备份能用。我习惯每周做一次restore validate database校验它能模拟恢复流程读取所有备份集验证备份片是否完整、是否存在损坏块整个过程不实际还原文件所以对生产影响很小成本远低于真的做一次 restore。命令可以挂在备份完成后的同一套 shell 里rman target / EOF restore validate database; EOF这段校验跑出来的日志里如果出现validation succeeded或Finished Restore Validate字样说明当前备份链是完整的如果报错就得立刻检查是哪一天的备份有问题提前处理。配合list backup summary;看备份集状态A代表 AvailableX代表 Expired出现大量X就说明磁盘上的备份文件已经丢了控制文件记录和物理文件对不上。除了校验更省心的做法是每个月在测试环境做一次真实的恢复演练。常见做法是利用已有的备份集在另一台服务器上做 restore 到一个临时目录然后 recover database 到最近的时间点验证完之后直接删掉。这个动作既验证备份也验证归档日志的完整性还能顺带练习恢复流程真出事时不至于手忙脚乱。演练最好留一份操作记录包括备份日期、恢复耗时、最终 recover 到的时间点方便复盘。自动报告方面我习惯把退出码和关键日志片段单独抽出来备份成功写BACKUP OK失败写BACKUP FAILED再用发邮件的命令通知值班人。报告里只需要三样东西本次级别、耗时、是否校验通过。不要发整段 RMAN 日志信息太多反而没人看。曾经有一次备份日志显示成功但我手贱做了次 restore validate发现上一周的 level 1 备份有坏块幸好恢复演练及时暴露了问题。从那以后我所有脚本都会强制加 validate 步骤宁可每次多花 20 分钟也不拿“应该没问题”赌生产。希望帮到你。本文还有配套的精品资源点击获取