保证归档日志不能随意被删除的四种方法
1.
SQL> alter system set log_archive_dest_2='service=testdb1dg lgwr async db_unique_name=slave MANDATORY';
2.
RMAN> CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON STANDBY;
或
RMAN>CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON ALL STANDBY
把它设置为CONFIGURE ARCHIVELOG DELETION POLICY TO NONE即取消了该限制
不过第二种方法的前提是已经有第一种方法的配置(第二种方法是第一种方法基础上的加强),否则会报错RMAN-08591: WARNING: invalid archived log deletion policy
以上两种方法适用于dataguard环境中的主库,保证主库日志不能随便被删除,不过主站上这两种方法都不推荐用,因为前提就是MANDATORY会导致主库hang住
3.
RMAN> configure archivelog deletion policy to backed up X times to device type disk;
以上x>=1时执行delete noprompt archivelog until time "sysdate-XX"会报错 RMAN-08138
把它设置为CONFIGURE ARCHIVELOG DELETION POLICY TO NONE即取消了该限制
以上三种方法都不会自动删除归档,(已经于20160120实验过的)。而是删除的时候确认是否符合条件,是避免删除其他功能所需要的归档日志。
4.
除以上三种情况外还存在的第四种特殊情况,即使没有上面三种设置,如果是dataguard环境中的备库,主库传输过来的归档日志还没有被备库 recover,此时备库执行delete noprompt archivelog until time "sysdate-XX"也会报错 RMAN-08137
如1和2两种方法则要确认归档是否已经被DATA GUARD所应用。,如果没有被DATA GUARD所应用,备份过程中执行delete all input或delete input或delete noprompt archivelog until time "sysdate-XX"都会报错
如果只是上面第一种方法则报错
RMAN-08137: WARNING: archived log not deleted, needed for standby or upstream capture process。
如果是上面第二种方法则报错
RMAN-08120: WARNING: archived log not deleted, not yet applied by standby
但是仍然可以通过OS层面来手工删除
MANDATORY选项不能随便配置在远程归档路径中,一旦选了后如果网络中断会出现如下情况,影响主库,导致主库hang住
ORA-16014: log 1 sequence# 565 not archived, no available destinations
个人实验经历
![](http://img.blog.itpub.net/blog/attachment/201607/19/30126024_1468899094IGtT.jpg?x-oss-process=style/bb)
![](http://img.blog.itpub.net/blog/attachment/201607/19/30126024_1468899112F99l.jpg?x-oss-process=style/bb)
![](http://img.blog.itpub.net/blog/attachment/201607/19/30126024_146889917293a8.jpg?x-oss-process=style/bb)
![](http://img.blog.itpub.net/blog/attachment/201607/19/30126024_1468899215tv4L.jpg?x-oss-process=style/bb)
来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/30126024/viewspace-1982071/,如需转载,请注明出处,否则将追究法律责任。
转载于:http://blog.itpub.net/30126024/viewspace-1982071/