Re: Best fs for Oracle RAC

From: DA Morgan <damorgan_at_psoug.org>
Date: Wed, 26 Sep 2007 09:18:38 -0700
Message-ID: <1190823508.470872@bubbleator.drizzle.com>

gerryt 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... : >

Generally speaking you don't create disk groups as a performance consideration but rather to partition storage.

If I want speed I get faster disks, more filer cache, stripe across more spindles, etc.

When I create additional disk groups, except with respect to failure, it is because I want to put some tablespaces into 15K disks due to the access pattern and older less accessed data onto 10K disks.

Others may use it to accomplish different goals.

-- 
Daniel A. Morgan
University of Washington
damorgan_at_x.washington.edu (replace x with u to respond)
Puget Sound Oracle Users Group
www.psoug.org

Received on Wed Sep 26 2007 - 11:18:38 CDT