Re: Oracle 10gR2 / RAID-5 / SAN

On Dec 21, 1:43 am, jeremy <jeremy0..._at_gmail.com> wrote:
> On Dec 20, 10:06 pm, joel garry <joel-ga..._at_home.com> wrote:
>
>
>
>
>
> > On Dec 20, 8:02 am, jeremy <jeremy0..._at_gmail.com> wrote:
>
> > > Hi folks
>
> > > Any pointers to any papers on the pros and cons of this kind of
> > > configuration?
>
> > > thanks
>
> > > --
> > > jeremy
>
> > In addition to baarf,http://kevinclosson.wordpress.com/?s=raidhttp://www.freelists.org/arc...
>
> > I've spent a lot of time on small RAID-5, and it does work.  However,
> > it is amazing how often things that are not supposed to happen do:
> > loss of more than one disk, saturation of I/O, controller
> > configuration issues, etc.  There used to be a bunch of papers about
> > vendors supporting small raid-5 hardware on oracle.com, when there was
> > some initiative to push it.  I had the sense that initiative was
> > marketing-driven, something having to do withhttp://www.oracle.com/partners/home/why_allusers/en/benefits.html.
>
> > You should at least get a commitment to allow some other configuration
> > for critical files that do better in other RAID configurations, should
> > they prove to be a problem.  From what I've seen, these would be
> > serial write intensive files like redo, archived redo and backups.
> > Also undo, simply because it is the most hit tablespace on the OLTP
> > types of db's that I tend to work on.  Since the backups and other
> > batch type jobs tend to happen after hours, no one much cares about
> > the I/O saturation as long as things complete in some reasonable time.
>
> > When it comes down to it, I take space over speed, if the speed isn't
> > enough, someone else will drive the political push for it.  I just
> > make sure I'm doing the best with what I have.
>
> I have been looking around for more info on this and came across:
>
> http://spiralbound.net/2006/09/08/why-modern-raid-5-is-ideal-for-orac...
>
> Here is an excerpt:
>
> "There is a convention of thought amongst Oracle DBA's that databases
> should never be installed on disks that are configured into a RAID 5
> array. The argument goes, that since Oracle accesses and writes to
> random points within relatively large files, the overhead of
> constantly calculating block-level parity on these files is
> substantial, resulting in serious performance degradation. They
> suggest that RAID 1 (mirroring) is the ideal disk configuration since
> no parity needs to be calculated, and Oracle is more than happy to
> divide up its database over many smaller mount points.
>
> This way of thinking has largely been correct over the years because
> most systems have traditionally used software RAID. This means that
> the CPU of the server itself had the job of doing all those parity
> calculations, and it really did slow down both the server and the disk
> when RAID 5 configurations were used. Oracle, in particular, had a
> hard time with these configurations for the exact reasons the DBA's
> point to.
>
> In many cases, software RAID is still used, and to be sure, it is
> wholly inappropriate to deploy RAID 5 in these environments. However,
> it is increasingly common to find IT departments using a SAN-type
> architecture where the RAID type and configuration are invisible to
> the host operating system. In these environments, the the disk array
> has a dedicated controller that is singly tasked with handling all
> read, write, and parity operations. The RAID controller is no longer
> software running on a generic CPU, but rather firmware that is
> optimized to handle parity calculations. This results in a system
> where parity is calculated so quickly by the dedicated controller that
> differences in speed between RAID 1 and Raid 5 should be virtually
> nonexistent."
>
> So.... does this alter the views of folk here? Reading this it would
> suggest that the issues of writer performance may be mitigated by the
> SAN managing everything.

Well, yeah, and that is why I mentioned saturation and controller configuration issues. Everything is fine until it isn't. At some point - and the point is unpredictable given the chaotic nature of increasing transaction volume in a real world system - there is a severe divergence between RAID 1 and RAID 5. Since hardware is so "cheap," it isn't all that hard to just throw a bunch at it, and if you don't run into a wall, and someone doesn't do anything stupid like believe MTBF figures or just put things together inappropiately (like single-pathing the controller), they're equivalent. Then the business grows and it goes to hell much earlier, and you can't do much because by then the SAN is fully populated and your capital budget is exhausted.

Those darn walls can hurt if you haven't protected your delicate parts. Don't just CYA, wear full body armor with an extra-thick codpiece.

jg

--
@home.com is bogus.
Someone call Jan Hammer!  http://www.physorg.com/news117283969.html