上周，为客户编写了一个RMAN备份的脚本，这周一客户来电告之说生产系统每天产生的归档日志有几G，每天要备全库二次（其实我是不建议这样的备份策略的，但客户坚持要这样），由于备份占用的空间太大，想在全备之后删除2天前备份的归档。
#find archpath -mtime 2 -exec rm -rf {} \;
这条命令是删除二天前系统生产的归档日志，并不是删除备份集中二天前的归档，这样做会与controlfile或者catalog的信息不一致。看下面的这条命令：
RMAN> backup archivelog all delete input|all;
delete后面只能接input或all参数，无法指定日期，显然也达不到客户要求，再来这条命令：
RMAN>backup archivelog until time ‘SYSDATE-2′ delete input;
该好像可以做到，但仔细一想，这条命令是备份2天前的归档日志然后将其删除而客户要求的是全备。
最后我们来看看下面的命令是否可以：
RMAN>delete noprompt archivelog until time ‘sysdate-2′;
这条命令是可以的达到客户要求的，注意一点，命令要放在备份语句之后。
如果事情做到这里的话，就不太完美，更重要的是我们是技术服务性的公司，应该站在客户的角度协助客户把系统管理得更好，更稳定。在RMAN备份中，还有一个参数：BACKUP OPTIMIZATION，备份优化。
RMAN中的备份优化是指在备份过程中，如果满足特定条件，RMAN将自动跳过某些文件而不将它们包含在备份集中以节省时间和空间,或者简单点就是能不备的就不备。一般在满足下面的条件下，才能够启用备份优化的功能：
1).BACKUP OPTIMIZATION参数置为OFF，使用下面的命令打开：
RMAN> CONFIGURE BACKUP OPTIMIZATION ON;
2).执行的BACKUP DATABASE或BACKUP ARCHIVELOG命令中带有ALL或LIKE参数。
3).分配的通道仅使用了一种设备类型，不能同时有sbt与disk的多个通道出现。
RMAN是如何判断要备份的文件是否需要被优化呢？算法就不追究了，影响优化算法的因素也是非常多的。
譬如客户的情况：在下午13：00执行一次全备，在凌晨1：00又执行一次全备，此时，备份的文件中没有变动而且又被备份过时，才会跳过这部分文件。理论上备份优化仅对于只读表空间或offline表空间起作用，但同时对于已经备份过的archivelog文件也会跳过不再备份。像客户的这种情况，如果没有设置backup optimization on, 有可能会重复备份归档日志。
有关更多的备份优化信息，猛击这里。
-The End-
