Re: Oracle and Raid setup

Frank van Bortel wrote:
> jeremypaulschneider_at_gmail.com wrote:
> > Cris Carampa wrote:
> >
> >>But Raid 1 gives you only fault tolerance, no performance gains because
> >>there is no striping. Or am I wrong?
> >
> >
> > no performance gains for writes; seems like you could get some gains
> > for reads since 2 different blocks could be read in parallel (1 from
> > each disk). how that works would depend on the implementation of RAID.
> >
>
> My understanding as well, but Nuno seems to disagree.

You are absolutely right in principle. But let's look at the reality of hardware implementations and what goes on behind the curtains.
Writes and reads don't just happen, they must be interpreted and scheduled like any other operation. This is the task of the low-level IO layers.

Writes are most of the time slower in RAID1 for a number of reasons (which might compound):

1- if RAID 1 is done via software (three major ways this can be: device driver, LVM, intelligent file system a-la vxfs), then two write channel programs must be passed to the disk controller(s) and waited for. Depending on how well the s/w handles asynch IO (and most don't do it well) then you got slowdown waiting for the return from the controller(s) and post-processing the return (making sure BOTH disk blocks have been written before completing the IO request - remember that there might be other concurrent accesses taking place and the controller has to sort out potential multiple requests and their returns).

2- if RAID 1 is done via the controller (or an intelligent subsystem like a SAN/etc), the OS issues a single write channel program and the controller splits it into two. And it has to wait for both disks to come back, then check that the "come back" WAS for the mirrored operation (asynch multi-string disk access particularly in SCSI controllers/SANs), and so on.

For reads:

in 1 above, there may be a possibility for the OS/database to be smart enough to split the read request and prioritise it correctly so the disk with the heads nearest to the required block is the one that gets the request while the other disk gets busy with something else. Don't bet your retirement on it...

in 2 above, particularly with sophisticated controller systems (SAN, NAS and a few other in-betweens), you get a much higher incidence of "one disk reads", provided the controller firmware (or OS in the case of the big boxes) is smart enough to keep stats of where each disk is, which one is nearest the required block, etcetc.

It's amazing the amount of complexity these things can jump into, particularly when you have concurrent access to multiple SCSI strings. While in theory, in a dedicated system, the double write might be a unary operation and the read a single disk one, in practice these things are highly contingent on the smarts of the IO hardware/firmware/device driver and implicitly on how much you paid!

You need a lot of moolah to make sure things stay the same way with concurrent access as with single access. Diminishing returns, overall bang for buck, "it depends" and all the other common-place caveats apply.

All this to say: don't assume RAID 1 can read faster and pay no penalty for writing. Reality will kick-in somewhere in there and throw the best plans of man and mice astray... ;) Received on Thu Jun 09 2005 - 20:12:06 CDT