archive redo log too small

198 Views

Hello,

On one ECC6.04 system with Oracle 11.2.0.2, we regularly have checkpoint is not complete.

Before re-increasing size or the number of redo groups again, I have check their sizes:

ls -altrh /oracle/PRD/oraarch

total 4269436

-rw-r--r-- 1 oraprd dba 0 Jun 15 2011 .ch.unige.nsr.ignore

--w------- 1 root root 500M Jun 21 2011 2_DELETE_ME_ON_ARCHIVER_STUCK

--w------- 1 root root 500M Jun 21 2011 1_DELETE_ME_ON_ARCHIVER_STUCK

-rw-r--r-- 1 root root 791 Jun 21 2011 0_DELETE_ME_ON_ARCHIVER_STUCK.README

-rw-r----- 1 oraprd dba 28M Apr 3 22:31 PRDarch1_10262_761304167.dbf

-rw-r----- 1 oraprd dba 35M Apr 3 23:27 PRDarch1_10263_761304167.dbf

-rw-r----- 1 oraprd dba 40M Apr 3 23:27 PRDarch1_10264_761304167.dbf

-rw-r----- 1 oraprd dba 40M Apr 3 23:27 PRDarch1_10265_761304167.dbf

-rw-r----- 1 oraprd dba 35M Apr 3 23:27 PRDarch1_10266_761304167.dbf

-rw-r----- 1 oraprd dba 30M Apr 3 23:27 PRDarch1_10267_761304167.dbf

-rw-r----- 1 oraprd dba 33M Apr 3 23:27 PRDarch1_10268_761304167.dbf

-rw-r----- 1 oraprd dba 29M Apr 3 23:28 PRDarch1_10269_761304167.dbf

-rw-r----- 1 oraprd dba 31M Apr 3 23:28 PRDarch1_10270_761304167.dbf

-rw-r----- 1 oraprd dba 29M Apr 3 23:28 PRDarch1_10271_761304167.dbf

-rw-r----- 1 oraprd dba 34M Apr 3 23:28 PRDarch1_10272_761304167.dbf

-rw-r----- 1 oraprd dba 40M Apr 4 00:13 PRDarch1_10273_761304167.dbf

-rw-r----- 1 oraprd dba 30M Apr 4 00:30 PRDarch1_10274_761304167.dbf

-rw-r----- 1 oraprd dba 32M Apr 4 00:30 PRDarch1_10275_761304167.dbf

-rw-r----- 1 oraprd dba 31M Apr 4 01:42 PRDarch1_10276_761304167.dbf

drwxr-xr-x 23 oraprd dba 42 Apr 4 02:23 ../

-rw-r----- 1 oraprd dba 28M Apr 4 04:32 PRDarch1_10277_761304167.dbf

-rw-r----- 1 oraprd dba 28M Apr 4 06:03 PRDarch1_10278_761304167.dbf

-rw-r----- 1 oraprd dba 30M Apr 4 06:30 PRDarch1_10279_761304167.dbf

-rw-r----- 1 oraprd dba 28M Apr 4 06:32 PRDarch1_10280_761304167.dbf

-rw-r----- 1 oraprd dba 28M Apr 4 06:33 PRDarch1_10281_761304167.dbf

-rw-r----- 1 oraprd dba 28M Apr 4 06:35 PRDarch1_10282_761304167.dbf

-rw-r----- 1 oraprd dba 28M Apr 4 06:36 PRDarch1_10283_761304167.dbf

-rw-r----- 1 oraprd dba 28M Apr 4 06:38 PRDarch1_10284_761304167.dbf

-rw-r----- 1 oraprd dba 28M Apr 4 06:39 PRDarch1_10285_761304167.dbf

-rw-r----- 1 oraprd dba 28M Apr 4 06:55 PRDarch1_10286_761304167.dbf

-rw-r----- 1 oraprd dba 35M Apr 4 06:56 PRDarch1_10287_761304167.dbf

-rw-r----- 1 oraprd dba 37M Apr 4 06:56 PRDarch1_10288_761304167.dbf

-rw-r----- 1 oraprd dba 35M Apr 4 06:56 PRDarch1_10289_761304167.dbf

-rw-r----- 1 oraprd dba 40M Apr 4 06:56 PRDarch1_10290_761304167.dbf

-rw-r----- 1 oraprd dba 40M Apr 4 06:56 PRDarch1_10291_761304167.dbf

-rw-r----- 1 oraprd dba 32M Apr 4 07:32 PRDarch1_10292_761304167.dbf

-rw-r----- 1 oraprd dba 27M Apr 4 09:32 PRDarch1_10293_761304167.dbf

-rw-r----- 1 oraprd dba 28M Apr 4 10:36 PRDarch1_10294_761304167.dbf

drwxr-xr-x 2 oraprd dba 40 Apr 4 11:04 ./

-rw-r----- 1 oraprd dba 28M Apr 4 11:04 PRDarch1_10295_761304167.dbf

It shows that the db is performing switch log before the max redo size is reached.

Would you know what could explain this wearied behavior?

Thanks in advance for your answer.