Oracle 11g归档日志的一个迷惑

民工甲V

两套Oracle 11g，配置了DataGuard，自己经过验证，DG状态正常，但就是有个归档日志的现象一直不理解，在10g环境下，归档日志占用的空间会不停增长，但同样的过程安装的11g，归档日志似乎在遵循着一个我不知道的策略自动清理。

SQL> select file_type,percent_space_used from v$flash_recovery_area_usage;
FILE_TYPE            PERCENT_SPACE_USED
-------------------- ------------------
CONTROL FILE                          0
REDO LOG                             .2
ARCHIVED LOG                          0
BACKUP PIECE                          0
IMAGE COPY                            0
FLASHBACK LOG                         0
FOREIGN ARCHIVED LOG                  0
7 rows selected.

这里的ARCHIVED LOG永远是0，

[oracle@senthdatam ~]$ ll /u01/oradata/db01/
total 108054236
-rw-r----- 1 oracle oinstall    24101376 Dec  6 00:26 1_11778_781805672.dbf
-rw-r----- 1 oracle oinstall    24178176 Dec  6 00:32 1_11779_781805672.dbf
-rw-r----- 1 oracle oinstall    24068096 Dec  6 00:37 1_11780_781805672.dbf
-rw-r----- 1 oracle oinstall    36474880 Dec  6 00:57 1_11781_781805672.dbf
-rw-r----- 1 oracle oinstall    38872064 Dec  6 01:37 1_11782_781805672.dbf
-rw-r----- 1 oracle oinstall    24178688 Dec  6 01:59 1_11783_781805672.dbf
-rw-r----- 1 oracle oinstall    24009216 Dec  6 02:07 1_11784_781805672.dbf
-rw-r----- 1 oracle oinstall    24158208 Dec  6 02:14 1_11785_781805672.dbf
-rw-r----- 1 oracle oinstall    24212992 Dec  6 04:14 1_11786_781805672.dbf
-rw-r----- 1 oracle oinstall    24009216 Dec  6 06:38 1_11787_781805672.dbf
-rw-r----- 1 oracle oinstall    23991296 Dec  6 08:04 1_11788_781805672.dbf
-rw-r----- 1 oracle oinstall    23977472 Dec  6 08:30 1_11789_781805672.dbf
-rw-r----- 1 oracle oinstall    24356352 Dec  6 08:45 1_11790_781805672.dbf
-rw-r----- 1 oracle oinstall    23981056 Dec  6 09:01 1_11791_781805672.dbf
-rw-r----- 1 oracle oinstall    24024576 Dec  6 09:12 1_11792_781805672.dbf
-rw-r----- 1 oracle oinstall    24046592 Dec  6 09:29 1_11793_781805672.dbf
-rw-r----- 1 oracle oinstall    24087040 Dec  6 09:37 1_11794_781805672.dbf
-rw-r----- 1 oracle oinstall    24285184 Dec  6 09:55 1_11795_781805672.dbf
-rw-r----- 1 oracle oinstall    24419328 Dec  6 10:07 1_11796_781805672.dbf
-rw-r----- 1 oracle oinstall    24009216 Dec  6 10:23 1_11797_781805672.dbf
-rw-r----- 1 oracle oinstall    24040960 Dec  6 10:46 1_11798_781805672.dbf
-rw-r----- 1 oracle oinstall    24115200 Dec  6 11:14 1_11799_781805672.dbf
-rw-r----- 1 oracle oinstall    24977408 Dec  6 12:12 1_11800_781805672.dbf
-rw-r----- 1 oracle oinstall    23984640 Dec  6 13:20 1_11801_781805672.dbf
-rw-r----- 1 oracle oinstall    23983616 Dec  6 13:56 1_11802_781805672.dbf
-rw-r----- 1 oracle oinstall    24089600 Dec  6 14:16 1_11803_781805672.dbf
-rw-r----- 1 oracle oinstall    23980544 Dec  6 14:47 1_11804_781805672.dbf
-rw-r----- 1 oracle oinstall    22790144 Dec  6 14:59 control01.ctl
-rw-r----- 1 oracle oinstall    52429312 Dec  6 14:16 redo01.log
-rw-r----- 1 oracle oinstall    52429312 Dec  6 14:47 redo02.log
-rw-r----- 1 oracle oinstall    52429312 Dec  6 14:59 redo03.log
-rw-r----- 1 oracle oinstall   964698112 Dec  6 14:58 sysaux01.dbf
-rw-r----- 1 oracle oinstall   754982912 Dec  6 14:59 system01.dbf
-rw-r----- 1 oracle oinstall 11156856832 Dec  6 13:38 temp01.dbf
-rw-r----- 1 oracle oinstall 24599601152 Dec  6 14:58 undotbs01.dbf
-rw-r----- 1 oracle oinstall 34359222272 Dec  6 14:59 users01.dbf
-rw-r----- 1 oracle oinstall 34359730176 Dec  6 14:59 users02.dbf
-rw-r----- 1 oracle oinstall  3485474816 Dec  6 14:59 users03.dbf

归档日志的那些dbf文件修改日期都是当天的，11804也确实是最新的。

RMAN> show all;
using target database control file instead of recovery catalog
RMAN configuration parameters for database with db_unique_name DB01 are:
CONFIGURE RETENTION POLICY TO REDUNDANCY 1; # default
CONFIGURE BACKUP OPTIMIZATION OFF; # default
CONFIGURE DEFAULT DEVICE TYPE TO DISK; # default
CONFIGURE CONTROLFILE AUTOBACKUP OFF; # default
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '%F'; # default
CONFIGURE DEVICE TYPE DISK PARALLELISM 1 BACKUP TYPE TO BACKUPSET; # default
CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
CONFIGURE MAXSETSIZE TO UNLIMITED; # default
CONFIGURE ENCRYPTION FOR DATABASE OFF; # default
CONFIGURE ENCRYPTION ALGORITHM 'AES128'; # default
CONFIGURE COMPRESSION ALGORITHM 'BASIC' AS OF RELEASE 'DEFAULT' OPTIMIZE FOR LOAD TRUE ; # default
CONFIGURE ARCHIVELOG DELETION POLICY TO NONE; # default
CONFIGURE SNAPSHOT CONTROLFILE NAME TO '/u01/oracle/product/11.2.0/db_1/dbs/snapcf_db01.f'; # default

我并没有配置归档日志的清理策略，到底是什么配置，在自动的处理归档日志，本人Oracle始终入不了门的，现在黔驴技穷，求各位指条明路！

民工甲V

补点信息

SQL> archive log list
Database log mode              Archive Mode
Automatic archival             Enabled
Archive destination            /u01/oradata/db01/
Oldest online log sequence     11803
Next log sequence to archive   11805
Current log sequence           11805

SQL> show parameter db_recover
NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
db_recovery_file_dest                string      /u01/flash_recovery_area
db_recovery_file_dest_size           big integer 200G

[oracle@senthdatam ~]$ ll /u01/flash_recovery_area/DB01/archivelog/
total 0

民工甲V

再补充，我发现在我的DG数据库，安装到现在的归档日志全在，已经达到近200G的文件

groovey

民工甲V 发表于 2012-12-6 15:17
补点信息

SQL> archive log list

上面显示很清楚，Archive destination  /u01/oradata/db01/
db_recover  /u01/flash_recovery_area  。
归档日志存放的目录下/u01/oradata/db01/ ，
flash_recovery_area   如果你没设置归档日志 目录，就会默认在这个的flash_recovery_area里面。
所以flash_recovery_area 里面根本没有归档日志，你查看select file_type,percent_space_used from v$flash_recovery_area_usage; 就一直是ARCHIVED LOG                          0

民工甲V

谢谢楼上的回复，

Archive destination            /u01/oradata/db01/
db_recovery_file_dest                string      /u01/flash_recovery_area

这两个目录，我前面说了，备库的/u01/oradata/db01/目录下，所有归档日志文件全在，近200G，可主库的/u01/oradata/db01/目录，上面贴过了，一直就是只有少数几个文件，给我的感觉，主库的归档日志应用到备库后，就被什么机制给处理了，而备库的至始至终都在。我们只需要关注备库的归档文件就行了？？

这个是11g的特性？？

groovey

民工甲V 发表于 2012-12-6 16:07
谢谢楼上的回复，

Archive destination            /u01/oradata/db01/

抱歉，是我没看清楚问题。你可以找下有没有定期删除主库归档的shell

民工甲V

回楼上，可以确定没有shell

不好意思，有点挖坟，但这个问题一直没找到原因