Re: Best fs for Oracle RAC

On Sep 26, 1:02 pm, gerryt <lepsys..._at_gmail.com> wrote:
> On Sep 24, 8:45 am, DA Morgan <damor..._at_psoug.org> wrote:
>
>
>
> > hjr.pyth..._at_gmail.com wrote:
> > > On Sep 24, 8:47 am, DA Morgan <damor..._at_psoug.org> wrote:
> > >> Bob Jones wrote:
> > >>>ASMwill not make migration to another platform easier or harder. The main
> > >>> advantage really is easier administration for DBAs when it's all setup, but
> > >>> not without drawbacks.
> > >> Wrong on both accounts. You just never stop with the wholesale ignorance
> > >> do you.
> > >>ASMmakes migration easier. As to drawbacks one can only assume that if
> > >> you actually knew of one you'd have named it so another classic BJ moment.
> > >> Yep, just another example of turning off the lights and throwing mud at
> > >> Oracle: Impressive. So far you've only managed to get yourself dirty.
> > > Well, just to abort the mud-pie contest before it really starts, how
> > > about explaining **how**ASMmakes migration easier? That is, how it
> > > makes turning a Windows database into a Solaris one (say) any easier
> > > than it would be in a non-ASMenvironment...;
> > Your use of Windows and Solaris confuses the issue. You are asking
> > about operating systems andASM is about storage. And not the
> > storage of your Oracle binaries.
> > Let me ask your question in a manner consistent with what ASM
> > is and does.
> > "... how it makes turning a database stored on an EMC filer into
> > one stored on a Hitachi filer"
> > If you can mount a disk system you can create an ASM diskgroup. If
> > you can create an ASM diskgroup you can migrate from it or to it.
>
> Out of curiousity how many diskgroups would/do/have you use for a
> "medium" sized database...? medium being relative I suppose : >
> I have fiddled a bit with several vs. one with swingbench
> set at 500 simultaneous users and I get the same
> benchmark numbers more or less. It seems there is no advantage to
> say, splitting up disk groups across several diskgroups, one for flash
> archiving
> , some for redo logs, and some for data etc..
>
> Say no matter how you scale it, and having a single diskgroup per db
> is just as good or better than several, it seems that having a single
> pool of disks managed
> by Oracle and and not requiring the SA to give out the root password
> to
> the DBAs makes migration "easier" in pre-engineering, rollout,
> production, and
> for OS maintenance windows later on. I think ASM should cut down a
> bit on
> vendor finger pointing too. Did my best to stay on topic here... : >

Fair enough.

I love ASM. I think it's definitely up there amongst the storage technologies of choice for any 10g+ Oracle deployment these days. Been saying that for years and am gratified to find other starting to say it now, too. I don't therefore see a problem with any of your list of advantages... but let's not over-egg the pudding!

It is NOT the case, generically, that one single disk group is best. See, for example, this PDF: http://download.oracle.com/oowsf2005/1973.pdf That explains how Amazon went about doing ASM, and they ended up with rather more than one disk group, and for well thought-out reasons that apply to big, small and in-between databases, not just giant ones.

And whereas you see the SA not needing to give out the root password as a plus, the fact that ASM makes storage management the job of the DBA and not so much the job of the SA is actually a potential political nightmare and a major obstacle to getting ASM deployed.

And on the issue of making "migration easier"... define "migration". Installation, yes. On-going support without 'vendor-pointing', absolutely. But *migration*? From what to what? As has already been established elsewhere in this thread: a migration from one storage vendor to another, yup, absolutely. But from one OS to another? Nope. Received on Tue Sep 25 2007 - 23:01:36 CDT