rman是oracle推出的官方备份还原工具。经过几个大版本的发展，rman已经支持多种备份介质和恢复策略的主要工具，也是业界普遍认可
rman是oracle推出的官方备份还原工具。经过几个大版本的发展，rman已经支持多种备份介质和恢复策略的主要工具，也是业界普遍认可是oracle备份还原官方策略。
archivelog是oracle备份还原策略的重要组成元素，不完全备份+连续的归档日志可以让我们将数据库恢复到发生故障点，实现数据的无损失恢复。但是，现实生活中archive log给没有经验的运维人员也带来了不少的问题，归档空间占满引起hang住、瞬间归档日志过多生成引起问题等。一些前辈也在不断强调“归档模式不美好”。
在rman工作参数中，针对archive log，是可以设置专门的删除策略（deletion）。在实践领域中，已经备份过或者确保安全传输的归档日志，其实就可以删除了，特别是在有限的fast recovery area管理模式下。对于自动删除archive log的策略，比较常见的是applied to standby和shipped to standby，也就是data guard场景下。
本篇介绍简单的backed up参数使用情况，并通过一系列实验去研究该参数影响下oracle和rman的工作行为特性。
1、基本参数和实验环境
笔者使用oracle 11gr2进行测试，具体版本编号为11.2.0.4。
sql> select * from v$version;
banner
--------------------------------------------------------------------------------
oracle database 11g enterprise edition release 11.2.0.3.0 - 64bit production
pl/sql release 11.2.0.3.0 - production
core 11.2.0.3.0 production
tns for linux: version 11.2.0.3.0 - production
nlsrtl version 11.2.0.3.0 – production
默认情况下，archivelog deletion policy参数为none。
rman> show all;
rman configuration parameters for database with db_unique_name xxxxdb are:
configure retention policy to redundancy 1; # default
（篇幅原因，有省略……）
configure archivelog deletion policy to none; # default
该参数常见的集中取值如下：
configure archivelog deletion policy to backed up 2 times to sbt;
configure archivelog deletion policy to backed up 1 times to device type disk;
configure archivelog deletion policy to applied on standby; --dg专用
configure archivelog deletion policy to shipped on standby; --dg专用
configure archivelog deletion policy clear;
研究archivelog行为最好的工具视图是v$archived_log。很多dba喜欢从操作系统层面删除归档日志，但是这种方式是不会直接被oracle控制文件认可，所以建议使用rman或者官方工具来做。
--已归档未删除日志
sql> select count(*) from v$archived_log where archived='yes' and deleted='no';
count(*)
----------
13
2、第一轮备份测试实验
首先我们修改archivelog deletion policy参数，设置为“两次备份后即可以删除”。
rman> configure archivelog deletion policy to backed up 2 times to device type disk;
new rman configuration parameters:
configure archivelog deletion policy to backed up 2 times to disk;
new rman configuration parameters are successfully stored
手工备份数据库和归档日志，不进行删除动作。
rman> backup database plus archivelog;
starting backup at 21-sep-15
current log archived
allocated channel: ora_disk_1
channel ora_disk_1: sid=16 device type=disk
channel ora_disk_1: starting archived log backup set
channel ora_disk_1: specifying archived log(s) in backup set
input archived log thread=1 sequence=100 recid=12 stamp=890690423
input archived log thread=1 sequence=101 recid=13 stamp=890712061
input archived log thread=1 sequence=102 recid=14 stamp=890727732
input archived log thread=1 sequence=103 recid=15 stamp=890776815
input archived log thread=1 sequence=104 recid=16 stamp=890776833
input archived log thread=1 sequence=105 recid=17 stamp=890805616
input archived log thread=1 sequence=106 recid=18 stamp=890814181
input archived log thread=1 sequence=107 recid=19 stamp=890820201
input archived log thread=1 sequence=108 recid=20 stamp=890859629
input archived log thread=1 sequence=109 recid=21 stamp=890892046
input archived log thread=1 sequence=110 recid=22 stamp=890900632
input archived log thread=1 sequence=111 recid=23 stamp=890906655
input archived log thread=1 sequence=112 recid=24 stamp=890942416
input archived log thread=1 sequence=113 recid=25 stamp=890990204
channel ora_disk_1: starting piece 1 at 21-sep-15
channel ora_disk_1: finished piece 1 at 21-sep-15
piece handle=/u01/app/oracle/fast_recovery_area/xxxxdb/backupset/2015_09_21/o1_mf_annnn_tag20150921t091644_bzypmwty_.bkp tag=tag20150921t091644
（篇幅原因，省略部分……）
finished control file and spfile autobackup at 21-sep-15
此时，归档日志被备份，并且没有删除。
--多出来的两个是由于进行备份时候自动会有switch log
sql> select count(*) from v$archived_log where archived='yes' and deleted='no';
count(*)
----------
15
下面进行第二次实验。
rman> backup database plus archivelog;
starting backup at 21-sep-15
current log archived
using channel ora_disk_1
channel ora_disk_1: starting archived log backup set
channel ora_disk_1: specifying archived log(s) in backup set
input archived log thread=1 sequence=100 recid=12 stamp=890690423
input archived log thread=1 sequence=101 recid=13 stamp=890712061
input archived log thread=1 sequence=102 recid=14 stamp=890727732
input archived log thread=1 sequence=103 recid=15 stamp=890776815
input archived log thread=1 sequence=104 recid=16 stamp=890776833
input archived log thread=1 sequence=105 recid=17 stamp=890805616
input archived log thread=1 sequence=106 recid=18 stamp=890814181
input archived log thread=1 sequence=107 recid=19 stamp=890820201
input archived log thread=1 sequence=108 recid=20 stamp=890859629
input archived log thread=1 sequence=109 recid=21 stamp=890892046
input archived log thread=1 sequence=110 recid=22 stamp=890900632
input archived log thread=1 sequence=111 recid=23 stamp=890906655
input archived log thread=1 sequence=112 recid=24 stamp=890942416
input archived log thread=1 sequence=113 recid=25 stamp=890990204
input archived log thread=1 sequence=114 recid=26 stamp=890990263
input archived log thread=1 sequence=115 recid=27 stamp=890990391
channel ora_disk_1: starting piece 1 at 21-sep-15
channel ora_disk_1: finished piece 1 at 21-sep-15
piece handle=/u01/app/oracle/fast_recovery_area/xxxxdb/backupset/2015_09_21/o1_mf_annnn_tag20150921t091951_bzypsqj3_.bkp tag=tag20150921t091951
（篇幅原因，有省略……）
finished control file and spfile autobackup at 21-sep-15
第二次备份，之前备份过的日志还出现在自动备份的列表中。但是，在第二次备份的时候，已经备份过两次（deletion policy）的日志并没有自动删除。
sql> select count(*) from v$archived_log where archived='yes' and deleted='no';
count(*)
----------
17
归档日志还在fast recovery area中。
[oracle@databaseintrawebpro fast_recovery_area]$ du -h
19m ./xxxxdb/autobackup/2015_09_21
9.4m ./xxxxdb/autobackup/2015_09_17
29m ./xxxxdb/autobackup
151m ./xxxxdb/onlinelog
6.0g ./xxxxdb/backupset/2015_09_21
108k ./xxxxdb/backupset/2015_09_17
6.0g ./xxxxdb/backupset
125m ./xxxxdb/archivelog/2015_09_19
27m ./xxxxdb/archivelog/2015_09_21
4.0k ./xxxxdb/archivelog/2015_09_15
127m ./xxxxdb/archivelog/2015_09_18
121m ./xxxxdb/archivelog/2015_09_20
4.0k ./xxxxdb/archivelog/2015_09_16
32m ./xxxxdb/archivelog/2015_09_17
431m ./xxxxdb/archivelog
9.4m ./xxxxdb/controlfile
6.6g ./xxxxdb
6.6g .
此时，归档日志和备份次数，在v$archived_log中可以方便的找出来。
sql> alter system switch logfile;
system altered
sql> select count(*) from v$archived_log where archived='yes' and deleted='no';
count(*)
----------
18
--注意这些已经备份过两次的recid编号
sql> select recid, sequence#, archived, deleted, backup_count from v$archived_log where backup_count>1;
recid sequence# archived deleted backup_count
---------- ---------- -------- ------- ------------
12 100 yes no 2
13 101 yes no 2
14 102 yes no 2
15 103 yes no 2
16 104 yes no 2
17 105 yes no 2
18 106 yes no 2
19 107 yes no 2
20 108 yes no 2
21 109 yes no 2
22 110 yes no 2
23 111 yes no 2
24 112 yes no 2
25 113 yes no 2
26 114 yes no 2
15 rows selected
进行第三次备份。
rman> backup database plus archivelog;
starting backup at 21-sep-15
current log archived
allocated channel: ora_disk_1
channel ora_disk_1: sid=498 device type=disk
skipping archived logs of thread 1 from sequence 100 to 114; already backed up
channel ora_disk_1: starting archived log backup set
channel ora_disk_1: specifying archived log(s) in backup set
input archived log thread=1 sequence=115 recid=27 stamp=890990391
input archived log thread=1 sequence=116 recid=28 stamp=890990481
input archived log thread=1 sequence=117 recid=29 stamp=890990667
input archived log thread=1 sequence=118 recid=30 stamp=890993128
channel ora_disk_1: starting piece 1 at 21-sep-15
channel ora_disk_1: finished piece 1 at 21-sep-15
piece
（篇幅原因，有省略…….）
finished control file and spfile autobackup at 21-sep-15
注意：备份过两次的日志，没有出现在rman自动备份的列表中。这里我们定义到了删除策略的一个行为：当满足删除条件的时候，归档日志是不会进入备份集合列表的。
归档日志信息：
sql> select recid, sequence#, archived, deleted, backup_count from v$archived_log where backup_count>1;
recid sequence# archived deleted backup_count
---------- ---------- -------- ------- ------------
12 100 yes yes 2
13 101 yes yes 2
14 102 yes yes 2
15 103 yes yes 2
16 104 yes yes 2
17 105 yes yes 2
18 106 yes yes 2
19 107 yes yes 2
20 108 yes yes 2
21 109 yes yes 2
22 110 yes yes 2
23 111 yes yes 2
24 112 yes yes 2
25 113 yes yes 2
26 114 yes no 2
27 115 yes no 2
28 116 yes no 2
17 rows selected
注意：一部分归档日志被删除，但是并没有所有上次备份过两次的日志都删除掉了，比如recid=26的日志。此时，备份fast recovery area空间情况发生了变化。
[oracle@databaseintrawebpro fast_recovery_area]$ du -h
29m ./xxxxdb/autobackup/2015_09_21
4.0k ./xxxxdb/autobackup/2015_09_17
29m ./xxxxdb/autobackup
151m ./xxxxdb/onlinelog
5.5g ./xxxxdb/backupset/2015_09_21
4.0k ./xxxxdb/backupset/2015_09_17
5.5g ./xxxxdb/backupset
4.0k ./xxxxdb/archivelog/2015_09_19
2.5m ./xxxxdb/archivelog/2015_09_21
4.0k ./xxxxdb/archivelog/2015_09_15
4.0k ./xxxxdb/archivelog/2015_09_18
4.0k ./xxxxdb/archivelog/2015_09_20
4.0k ./xxxxdb/archivelog/2015_09_16
4.0k ./xxxxdb/archivelog/2015_09_17
2.6m ./xxxxdb/archivelog
9.4m ./xxxxdb/controlfile
5.7g ./xxxxdb
5.7g .
在alert log中，我们看到了oracle自动删除的动作。
mon sep 21 09:24:27 2015
expanded controlfile section 11 from 28 to 56 records
requested to grow by 28 records; added 1 blocks of records
archived log entry 29 added for thread 1 sequence 117 id 0x774e158c dest 1:
mon sep 21 10:05:28 2015
alter system archive log
mon sep 21 10:05:28 2015
thread 1 advanced to log sequence 119 (lgwr switch)
current log# 2 seq# 119 mem# 0: /u01/app/oracle/oradata/xxxxdb/onlinelog/o1_mf_2_bxzzjj5w_.log
current log# 2 seq# 119 mem# 1: /u01/app/oracle/fast_recovery_area/xxxxdb/onlinelog/o1_mf_2_bxzzjj80_.log
archived log entry 30 added for thread 1 sequence 118 id 0x774e158c dest 1:
mon sep 21 10:05:47 2015
deleted oracle managed file /u01/app/oracle/fast_recovery_area/xxxxdb/backupset/2015_09_17/o1_mf_annnn_tag20150917t195557_bzoblfck_.bkp
deleted oracle managed file /u01/app/oracle/fast_recovery_area/xxxxdb/archivelog/2015_09_17/o1_mf_1_100_bzokvqj0_.arc
deleted oracle managed file /u01/app/oracle/fast_recovery_area/xxxxdb/autobackup/2015_09_17/o1_mf_s_890682958_bzoblglw_.bkp
deleted oracle managed file /u01/app/oracle/fast_recovery_area/xxxxdb/archivelog/2015_09_18/o1_mf_1_101_bzp6zx31_.arc
deleted oracle managed file /u01/app/oracle/fast_recovery_area/xxxxdb/archivelog/2015_09_18/o1_mf_1_102_bzpp9nln_.arc
deleted oracle managed file /u01/app/oracle/fast_recovery_area/xxxxdb/archivelog/2015_09_18/o1_mf_1_103_bzr67h1h_.arc
deleted oracle managed file /u01/app/oracle/fast_recovery_area/xxxxdb/archivelog/2015_09_18/o1_mf_1_104_bzr6812s_.arc
deleted oracle managed file /u01/app/oracle/fast_recovery_area/xxxxdb/archivelog/2015_09_19/o1_mf_1_105_bzs2cj5y_.arc
deleted oracle managed file /u01/app/oracle/fast_recovery_area/xxxxdb/archivelog/2015_09_19/o1_mf_1_106_bzsbq54p_.arc
deleted oracle managed file /u01/app/oracle/fast_recovery_area/xxxxdb/archivelog/2015_09_19/o1_mf_1_107_bzsjm99v_.arc
deleted oracle managed file /u01/app/oracle/fast_recovery_area/xxxxdb/archivelog/2015_09_19/o1_mf_1_108_bztq3f2v_.arc
deleted oracle managed file /u01/app/oracle/fast_recovery_area/xxxxdb/archivelog/2015_09_20/o1_mf_1_109_bzvprgf1_.arc
deleted oracle managed file /u01/app/oracle/fast_recovery_area/xxxxdb/archivelog/2015_09_20/o1_mf_1_110_bzvz4rj7_.arc
deleted oracle managed file /u01/app/oracle/fast_recovery_area/xxxxdb/archivelog/2015_09_20/o1_mf_1_111_bzw50zmb_.arc
deleted oracle managed file /u01/app/oracle/fast_recovery_area/xxxxdb/archivelog/2015_09_20/o1_mf_1_112_bzx7yj9g_.arc
deleted oracle managed file /u01/app/oracle/fast_recovery_area/xxxxdb/archivelog/2015_09_21/o1_mf_1_113_bzypmw8c_.arc
deleted oracle managed file /u01/app/oracle/fast_recovery_area/xxxxdb/backupset/2015_09_21/o1_mf_annnn_tag20150921t091644_bzypmwty_.bkp
mon sep 21 10:05:58 2015
deleted oracle managed file /u01/app/oracle/fast_recovery_area/xxxxdb/backupset/2015_09_21/o1_mf_nnndf_tag20150921t091647_bzypn055_.bkp
mon sep 21 10:06:15 2015
alter system archive log
mon sep 21 10:06:15 2015
thread 1 advanced to log sequence 120 (lgwr switch)
current log# 3 seq# 120 mem# 0: /u01/app/oracle/oradata/xxxxdb/onlinelog/o1_mf_3_bxzzjl0z_.log
current log# 3 seq# 120 mem# 1: /u01/app/oracle/fast_recovery_area/xxxxdb/onlinelog/o1_mf_3_bxzzjl35_.log
archived log entry 31 added for thread 1 sequence 119 id 0x774e158c dest 1: