记录一则RMAN备份策略修正案例
记录一则RMAN备份策略修正案例
背景：在给某客户处理问题时，发现客户数据库的备份空间即将用尽，进一步查看发现是用户数据库的当前RMAN备份策略存在潜在问题，需要修改备份策略。
环境：SunOS 5.10 + Oracle 11.2.0.3
1.分析当前RMAN备份策略的问题
1.1 查看系统任务调度
``` -bash-3.2$ crontab -l 0 0 * * 0 /oradata03/backup/rman/db_full.sh > /dev/null 2&>1# 0 0 * * 1-6 /oradata03/backup/rman/db_level1.sh > /dev/null 2&>1# ``` 可以看到，第一条是每周日凌晨0点执行/oradata03/backup/rman/db_full.sh脚本； 第二条是每周一～周六凌晨0点执行/oradata03/backup/rman/db_level1.sh脚本。 这部分中，调度本身是没有问题的。1.2 查看任务调度脚本内容
查看/oradata03/backup/rman/db_full.sh脚本内容： ``` -bash-3.2$ more /oradata03/backup/rman/db_full.sh #/usr/bin/ksh #rman incremental backup level=0 ORACLE_BASE=/opt/app/oracle/ ORACLE_HOME=/opt/app/oracle/product/11.2.3 ORACLE_SID=xxoradb PATH=$ORACLE_HOME/bin:$PATH:. export ORACLE_BASE ORACLE_HOME ORACLE_SID PATH (rman target / @/oradata03/backup/rman/db_full.rcv df -g )>/oradata03/backup/full_`date +%m%d%y`.log ``` 查看/oradata03/backup/rman/db_level1.sh脚本内容： ``` -bash-3.2$ more /oradata03/backup/rman/db_level1.sh #/usr/bin/ksh #RMAN incremental backup level=1
ORACLE_BASE=/opt/app/oracle/ ORACLE_HOME=/opt/app/oracle/product/11.2.3 ORACLE_SID=xxoradb PATH=ORACLE_HOME/bin:PATH:. export ORACLE_BASE ORACLE_HOME ORACLE_SID PATH (rman target / @/oradata03/backup/rman/db_level1.rcv df -g )>/oradata03/backup/weekly_level1_date +%m%d%y.log这部分中，脚本本身是没有问题的。 1.3 查看上面2个脚本中的嵌套内容 查看/oradata03/backup/rman/db_full.sh脚本内容中嵌套的/oradata03/backup/rman/db_full.rcv内容：
-bash-3.2$ more /oradata03/backup/rman/db_full.rcv
run{
backup format '/oradata03/backup/full_%s_%p_%t.bak' database plus archivelog delete input;
crosscheck backup;
delete noprompt expired backup;
delete noprompt obsolete;
}查看/oradata03/backup/rman/db_level1.sh脚本内容中嵌套的/oradata03/backup/rman/db_level1.rcv内容：
-bash-3.2$ more /oradata03/backup/rman/db_level1.rcv
run{
backup incremental level=1 format '/oradata03/backup/level1_%s_%p_%t.bak' database plus archivelog delete input;
}这部分产生第1个疑问：db_full.rcv里面的内容是普通的数据库全备+归档，而db_level1.rcv里面内容是1级增量+归档。 我们知道，1级增量备份依据的是0级增量备份，而这里的普通数据库全备是不能作为1级增量备份的基础的， 所以，第一想法是这里面的1级增量备份是没有必要的，白白浪费了系统资源和备份的磁盘空间。 而有意思的是，我实际在测试环境测试发现：**如果只做1级增量备份，没有做0级增量的话，那么Oracle会默认第一次先做0级增量。以保证备份的有效性。** 不过还是建议能够显性的指定到底是0级增量还是1级增量，不然会给管理维护带来不必要的困扰。具体参照本文第二部分。 1.4 查看RMAN保留策略相关 查看RETENTION POLICY：
CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 15 DAYS;查看control_file_record_keep_time参数：
SQL> show parameter control_file_record_keep_time
NAME TYPE VALUE
----
control_file_record_keep_time integer 7<font color="red">这部分产生第2个疑问：control_file_record_keep_time参数是默认值7天，而RECOVERY WINDOW是15天，这样有可能导致备份信息条目丢失，建议设置control_file_record_keep_time值=RECOVERY WINDOW + 1. 这里就是16.</font> 有关这个control_file_record_keep_time参数设置什么值最合适，网上说法不一，我专门咨询了maclean大神，回复是 > 一般设置为 CONTROL_FILE_RECORD_KEEP_TIME = recovery window+1 即可 > 实际 控制文件记录的覆盖 和 recovery window没有直接的关系，所以不用过度担忧。 control_file_record_keep_time是动态参数，可以直接修改：
alter system set control_file_record_keep_time = 16;2.拟出解决方案供客户选择 发现问题就要解决问题，针对1.3中的问题，我想出2个解决方案供用户选择。当然，不改造也是可以的。 2.1 解决方案一 **将1级增量备份内容修改为只备份归档** 即将/oradata03/backup/rman/db_level1.rcv文件中的内容修改为：
-bash-3.2$ more /oradata03/backup/rman/db_level1.rcv
run{
backup archivelog all delete input format '/oradata03/backup/arch_%s_%p_%t.bak';
}当然只改动这个就已经实现了功能，但为了易于后期维护，建议将脚本文件的名称及关联内容也修改一下：
文件名称修改： /oradata03/backup/rman/db_level1.rcv -> /oradata03/backup/rman/db_arch.rcv
文件内容修改： /oradata03/backup/rman/db_level1.sh 文件内容中的 db_level1.rcv -> db_arch.rcv
文件名称修改： /oradata03/backup/rman/db_level1.sh -> /oradata03/backup/rman/db_arch.sh
调度内容修改： crontab -e 修改内容 db_level1.sh -> db_arch.sh2.2 解决方案二 **将普通全备内容修改为0级增量备份** 即将/oradata03/backup/rman/db_full.rcv文件中的内容修改为：
-bash-3.2$ more /oradata03/backup/rman/db_full.rcv
run{
backup incremental level=0 format '/oradata03/backup/level0_%s_%p_%t.bak' database plus archivelog delete input;
crosscheck backup;
delete noprompt expired backup;
delete noprompt obsolete;
}在不考虑只读表空间的情况下，0级增量就相当于数据库的全备，不同的是0级增量可以作为1级增量的基础。 然后同样为了易于后期维护，建议将脚本文件的名称及关联内容也修改一下：
文件名称修改： /oradata03/backup/rman/db_full.rcv -> /oradata03/backup/rman/db_level0.rcv
文件内容修改： /oradata03/backup/rman/db_full.sh 文件内容中的 db_full.rcv -> db_level0.rcv
文件名称修改： /oradata03/backup/rman/db_full.sh -> /oradata03/backup/rman/db_level0.sh
调度内容修改： crontab -e 修改内容 db_full.sh -> db_level0.sh2.3 两个方案对比 方案一：简单好管理。但恢复时有可能不如第二种快。 方案二：复杂一些。相对第一种多一个增量备份，恢复时一般会比第一种快。 目前两种方案都可以满足客户需求，由客户决定选择哪一种方案。 3.根据实际情况决定删除无用历史备份 由于control_file_record_keep_time参数设置有误，RMAN没有成功删除所有保留窗口之外的备份信息。 需要DBA手工确认删除无用历史备份。
RMAN> list backup of database summary;List of Backups
Key TY LV S Device Type Completion Time #Pieces #Copies Compressed Tag
----
3625 B F A DISK 2015-09-13 00:02:05 1 1 NO TAG20150913T000035
3626 B F A DISK 2015-09-13 00:02:30 1 1 NO TAG20150913T000035
3627 B F A DISK 2015-09-13 00:02:55 1 1 NO TAG20150913T000035
3628 B F A DISK 2015-09-13 00:03:18 1 1 NO TAG20150913T000035
3629 B F A DISK 2015-09-13 00:03:28 1 1 NO TAG20150913T000035
3634 B 1 A DISK 2015-09-14 00:02:42 1 1 NO TAG20150914T000034
3635 B 1 A DISK 2015-09-14 00:03:08 1 1 NO TAG20150914T000034
3636 B 1 A DISK 2015-09-14 00:03:33 1 1 NO TAG20150914T000034
3637 B 1 A DISK 2015-09-14 00:03:58 1 1 NO TAG20150914T000034
3638 B 1 A DISK 2015-09-14 00:04:07 1 1 NO TAG20150914T000034
3642 B 1 A DISK 2015-09-15 00:01:16 1 1 NO TAG20150915T000028
3643 B 1 A DISK 2015-09-15 00:01:45 1 1 NO TAG20150915T000028
3644 B 1 A DISK 2015-09-15 00:02:10 1 1 NO TAG20150915T000028
3645 B 1 A DISK 2015-09-15 00:02:35 1 1 NO TAG20150915T000028
3646 B 1 A DISK 2015-09-15 00:02:42 1 1 NO TAG20150915T000028
3651 B 1 A DISK 2015-09-16 00:02:19 1 1 NO TAG20150916T000105
3740 B 1 A DISK 2016-02-16 01:24:59 1 1 NO TAG20160216T011603
3741 B 1 A DISK 2016-02-16 01:28:50 1 1 NO TAG20160216T011603
3742 B 0 A DISK 2016-02-16 01:29:24 1 1 NO TAG20160216T011603
3743 B 1 A DISK 2016-02-16 01:29:43 1 1 NO TAG20160216T011603
3747 B 1 A DISK 2016-02-17 00:04:46 1 1 NO TAG20160217T000029
3748 B 1 A DISK 2016-02-17 00:06:46 1 1 NO TAG20160217T000029
3749 B 1 A DISK 2016-02-17 00:07:29 1 1 NO TAG20160217T000029
3750 B 1 A DISK 2016-02-17 00:08:03 1 1 NO TAG20160217T000029
3751 B 1 A DISK 2016-02-17 00:08:13 1 1 NO TAG20160217T000029可以看到最早可读的全备份是在2015-09-13 00:02:05这个时间点，那么这个时间点之前的备份文件实际是可以清理掉的。 根据前面备份脚本，可以确定目录下后缀为`.log`和`.bak`可以清除掉，如何获取到这个时间点之前呢？
SQL> select sysdate-158 from dual;SYSDATE-158
2015/9/12 1find查找158天前创建的后缀为`.log`和`.bak`的文件数量：
-bash-3.2$ find *.log -mtime +158|wc -l
254
-bash-3.2$ find *.bak -mtime +158|wc -l
1021确定都是要删除的无用文件后，可以删除掉：
find *.log -mtime +158|xargs rm -rf
find *.bak -mtime +158|xargs rm -rf最后验证下RMAN备份是否受到影响（当然不会受到影响了，我前面删除的都是无用的历史文件），
--交叉验证备份文件有效性
RMAN> crosscheck backup;
输出略..（实际都是available状态的备份文件，说明我之前删除的文件确实是没用的）
--删除保留策略之外的文件
RMAN> delete obsolete;
RMAN retention policy will be applied to the command
RMAN retention policy is set to recovery window of 15 days
using channel ORA_DISK_1
no obsolete backups found
--删除过期的备份文件（这里没有，再次说明了我之前删除的文件确实是没用的）
RMAN> delete expired backup;
using channel ORA_DISK_1
specification does not match any backup in the repository
--看当前数据库有哪些文件需要备份（没有结果）。
RMAN> report need backup;
RMAN retention policy will be applied to the command
RMAN retention policy is set to recovery window of 15 days
Report of files that must be backed up to satisfy 15 days recovery window
File Days Name
----
RMAN>此时再看，备份目录的空间终于大幅得到了释放。解决了问题。 4.总结
这个案例，导致备份目录满的根本原因是control_file_record_keep_time参数设置有误，导致控制文件中的条目信息不完整，进而导致历史无用的备份文件没有被RMAN自动删除。 而对于表面看来像是普通全备+1级增量的概念性问题，实际上却是有隐性执行0级增量的过程，让人有点乌龙的感觉。甚至这样写还能起到简化脚本的作用，就是容易给人造成困扰吧。 虽然最终看来，只是一个动态参数的设置问题导致的故障。但解决的过程真的是很丰富，也用到了很多理论和实践验证，值得记录下来和以后回味。
腾讯云开发者
