Re: DB RAID Setup

From: Greg Rahn <>
Date: Wed, 10 Dec 2008 14:29:57 -0800
Message-ID: <>

The first thing I would recommend is to look at v$event_histogram. This will give you a breakdown of where the times are falling into. Averages from AWR, etc, can be very misleading in this case.

select wait_time_milli, count(*)
from v$event_histogram
where event='log file sync'
group by wait_time_milli
order by 1


--------------- ----------------
	      1 	       1
	      2 	       1
	      4 	       1
	      8 	       1
	     16 	       1
	     32 	       1
	     64 	       1
	    128 	       1
	    256 	       1
	    512 	       1

(output for reference only)

You could also do a weighted average (wait_time_milli * count(*)) to get a "biggest bucket" view. Sometimes a few large values can be very problematic. On very busy systems these will stall and cause an issue where the system doesn't recover until load drops significantly.

Second, there are a bunch of bugs that relate to log file sync. 7452373
Work with Oracle support on these. Some are RAC specific. These are all fixed in and One offs are available I believe.

Good luck!

On Tue, Dec 9, 2008 at 1:17 PM, Martin Brown <> wrote:
> I have a similar question regarding raid 5 and what I perceive to be a
> "potential" problem. I am experiencing a high number of logfile sync waits
> that appear most afternoons as the daily load starts to increase. We're
> running RAC with a 8 node cluster. We use a 3par storage system for
> the database. My architect has configured both raid 1 and raid 5 diskgroups
> and he duplexes the online redo logs and controlfiles to raid5.
> Now, he insists that the logfile sync waits are not related in any way to
> the raid5 configuration and the 3par storage solution is
> state-of-the-art. But the only remedy I can find is to move to faster SSD.
> Is it possible that the high afternoon activity coupled with the raid5
> configuration is the root of my problem?
> I've looked at other stuff too. The log switches are 2 - 3 an hour. The log
> buffer is never full. Anyone have any other suggestions as to where to look?

Greg Rahn
Received on Wed Dec 10 2008 - 16:29:57 CST

Original text of this message