I am guessing that you are in archive log mode. If so then you are saying that it is taking 1200ms to copy a 50mb file. Given that you are doing 600 megs of redo per hour it sounds like it is fine.
There is an article on metalink regarding increasing the size of your log buffer. Doc ID: 26904.996
From: Oracle, Tom Villane 29-Sep-00 18:52
Subject: Re : INCREASING THE PARAMETER : LOG_BUFFER
If a user process has to wait for the LGWR to move redo entries from the buffer to the log files on disk, then it can affect performance. You can check to see if any users are waiting on buffer space by using the following. SELECT name, value FROM v$sysstat WHERE name = 'redo log space requests';
The value of "redo log space requests" should be near 0. If this value increments consistently, processes have had to wait for space in the buffer. This may be caused by the log buffer being too small, or it could be caused by the checkpointing or log switching.
The is no danger in making it larger. If an instance crashes, any uncommitted transactions are lost anyway. Making it larger uses more memory which could be used somewhere else.
How did you get the figure of 600M of redo??
THe log switches occurs like every 2 hrs during normal activity.
THE reason I am worried is whenever there is high activity(in fact any large update or inserts with LOBs) the redo logs switch every minute (even with 14 50M groups) this average wait goes up a lot and results in checkpoint not complete/aiowait errors, I don't want the system to crash during high load.
You have 14 groups of 50MB each and you say that during high activity you still get checkpoint not complete messages. This implies that the archiver is not writing the data fast enough to disk to free up the space in online redo logs. Check you IO response times for the disk holding the archive directory. If you find contentions on this disk move the archive directory to a faster disk. Another way is to change your redo file size to 100MB to make more room in online redo logs.
I thought you were saying that you were doing log switches every 5-6 minutes. Certainly disk contention would be a factor. I would also say that the larger to logfile, the longer it will take to archive. You might want to run the SELECT name, value FROM v$sysstat WHERE name = 'redo log space requests'; query. You should increase the log buffer and maybe even add more log groups. I don't think that there is a single answer for this. There are probably several combinations that you could try that would work.
As I read somewhere it is either 1/3rd of the log buffer or 1M.
I increased it to this size(1.7M) as the log writes was slow, so I thought as the log buffer is small the 1/3 portion is getting filled up quickly and thereby sending too many quick requests to the LGWR which in turn slows up the redo writes.
I saw some improvement in the redo writes after I increased(doubled up) the size of the Log buffer, but still during log switches or certain high activity it goes up to 1000ms.
So I think the problem might be with IO.
1) Make redologs bigger so that average time gap between redo log switch is 20-30mns.
2) Make sure redo logs are not created on disks of large stripe size or on RAID5 disks.
3) Try to create raw redo log files
4) Be sure the prcoess paramter is not much higher than required.
5) Be sure redo copy latches are not much higher than required.
6) At OS level try to find if LGWR process has a I/O wait or bottleneck.