首先我们来看下什么是archive log file，Oracle 11g 的concept中是这样定义的：When you enable archiving of the online redo logs, Oracle Database copies the online redo log files to another location before they are overwritten. These copied files are referred to as archived redo log files. 那么根据这个定义，archive log file就是redo log file的拷贝，既然是拷贝，在排除压缩的情况下，两种文件的大小应该是一致的。但是我们在真实环境中看到的archive log file就是redo log file却不是一样大，真实情况是archive log file比redo log file小，极端情况下，甚至会小非常多。
引起archive log file就是redo log file大小不一致的原因大致有如下几种：
一、人为操作类型
1、SQL>alter system switch logfile;
2、SQL>alter system archive log current;
3、RMAN>backup archive log all;
4、RMAN>backup database plus archivelog;
二、参数设置类型
archive_lag_target：日志切换的强制时间间隔，即只要到达该参数设置的时间间隔，无论redo 文件是否写满，都会进行日志切换。
三、oracle bug类型
BUG 9272059、BUG 10354739、BUG 12317474、BUG 5450861、BUG 7016254
下面对archive log file就是redo log file大小不一致的原因进行分析，首先，如果redo log file中是以空白结尾，那么，archive log file中会将末尾的空白去除，这就样就会出现archive log比redo log file小，具体小多少，就根据归档时redo log file末尾的空白大小决定。这种情形常见于前面提到的认为操作类型和参数设置类型。因为在进行强制切换日志的时候，redo log file是没有被写满的，文件的末尾必然存在空白。
另外，日志切换并不是发生redo log file 100%满的时候，这是由于oracle的内部算法决定的，这样做的主要目的是处于性能的考虑。所以redo log file始终不会被100%的写满，在进行归档的时候，末尾的空白会被丢弃，所以就导致了archive log file小于redo log file。影响redo log切换时间的因素有：LOG_BUFFER_SIZE参数设置、系统负载、log file size、logfile 空间分配算法。
CUP_COUNT值会影响logfile空间分配算法，所以，如果出现日志频繁切换且归档日志远小于redo log file的情况，请检查CUP_COUNT是否符合系统的实际情况。
再次，如果是RAC环境，如果各节点的负载不一致，为了保证数据库的可恢复性，空闲节点会进行一些的日志切换，主要是为了增进redo 日志的FIRST_CHANGE#，空闲节点产生的归档日志大小会与redo file大小有较大差距。下面进行验证：
--查看redo file大小
SQL> select thread#,group#,bytes/1024/1024 "size" from v$log order by 1,2;
THREAD# GROUP# size
---------- ---------- ----------
1 1 50
1 2 50
2 3 50
2 4 50
--在节点1上建立测试表
SQL> create table darren(id number,item varchar2(2));
--查看当前的归档情况和redo log的FRIST_CHANGE#
SQL> select thread#,name,blocks*block_size/1024/1024 "size" from v$archived_log order by 1,2;
THREAD# NAME size
---------- ---------------------------------------------------------------------- ----------
1 +DATADG01/gyl/archivelog/2014_10_23/thread_1_seq_10.268.861729569 1.4453125
1 +DATADG01/gyl/archivelog/2014_10_23/thread_1_seq_11.270.861730475 49.9980469
1 +DATADG01/gyl/archivelog/2014_10_23/thread_1_seq_12.271.861730509 49.9980469
1 +DATADG01/gyl/archivelog/2014_10_23/thread_1_seq_13.272.861730545 49.9980469
1 +DATADG01/gyl/archivelog/2014_10_23/thread_1_seq_14.274.861730573 49.9980469
1 +DATADG01/gyl/archivelog/2014_10_23/thread_1_seq_15.275.861730601 49.9980469
1 +DATADG01/gyl/archivelog/2014_10_24/thread_1_seq_16.276.861788401 35.8242188
2 +DATADG01/gyl/archivelog/2014_10_23/thread_2_seq_2.269.861729571 2.37207031
2 +DATADG01/gyl/archivelog/2014_10_23/thread_2_seq_3.273.861730551 .008300781
2 +DATADG01/gyl/archivelog/2014_10_24/thread_2_seq_4.277.861788403 .567871094
SQL> select GROUP#,THREAD#,SEQUENCE#,STATUS,FIRST_CHANGE# from v$log order by 2;
GROUP# THREAD# SEQUENCE# STATUS FIRST_CHANGE#
---------- ---------- ---------- ---------------- -------------
1 1 17 CURRENT 794878
2 1 16 INACTIVE 700672
3 2 5 CURRENT 794876
4 2 4 INACTIVE 517670
--在节点1上进行事务，由于是测试环境，节点2上完全没事务，是空闲实例
begin
for i in 1..500000 loop
insert into darren values(1,'aa');
commit;
end loop;
end;
--查看归档情况和redo log 的FRIST_CHANGE#
SQL> select thread#,name,blocks*block_size/1024/1024 "size" from v$archived_log order by 1,2;