-
My average redo write time is very high(goes upto 1200ms)
during log switches like for 5-6 minutes, how do I resolve this.
My log buffer size is 1.5M and we have 14 groups of redo log sized 50m each.
THanx in advance for any help.
KN
-
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
Hi,
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.
Regards
Tom Villane
Metalink Analyst
-
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.
Please adise.
Thanx
KN
-
Hi,
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.
Baliga
-
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.
-
Your choke point could be in the I/O. So check to see how it performs. Is your redo and archives are on seperate disks?
Sam
Thanx
Sam
Life is a journey, not a destination!
-
Isn't the log buffer flushed at 1mB regardlesss ?
Thus it would be pointless to increase over 1MB
Once you have eliminated all of the impossible,
whatever remains however improbable,
must be true.
-
Originally posted by Sureshy
Isn't the log buffer flushed at 1mB regardlesss ?
Thus it would be pointless to increase over 1MB
Yes, it is pointless to have LOG_BUFFER > 1M.
-
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.
My logfiles and archives are on different disks.
KN
-
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.
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules
|
Click Here to Expand Forum to Full Width
|