Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> c.d.o.server -> Re: Best fs for Oracle RAC

Re: Best fs for Oracle RAC

From: <hjr.pythian_at_gmail.com>
Date: Mon, 24 Sep 2007 16:18:49 -0700
Message-ID: <1190675929.841720.60290@19g2000hsx.googlegroups.com>


On Sep 25, 6:12 am, joel garry <joel-ga..._at_home.com> wrote:
> On Sep 24, 11:24 am, hjr.pyth..._at_gmail.com wrote:
>
>
>
> > On Sep 25, 3:16 am, Steve Howard <stevedhow..._at_gmail.com> wrote:
>
> > > I agree with this. To provide an actual real-life specific example,
> > > we switched from IBM FAStT storage to EMC by adding the EMC disks to
> > > the existing diskgroup (originally with only FAStT storage). Once the
> > > rebalance to include the EMC disks had completed, we dropped the FAStT
> > > disks from the diskgroup. Clean and easy.
>
> > > Regards,
>
> > > Steve
>
> > As a fan of ASM, it's always nice to see the good stories. But what
> > you've described is not a "migration" in my book. If I had to pick a
> > word, it's a "transition" from one storage vendor to another. No less
> > a powerful demonstration of ASM's capabilities for all that, of
> > course... but not (I suspect) what the OP and Bob were originally
> > talking about.
>
> I have no opinion about ASM. The original post specified hp-ux and
> linux, and those two platforms have some quite different configuration
> issues with respect to raw - for that matter, even different versions
> of hp-ux are different. So for Bob to say "Raw is the simplest and
> the most reliable option and if you are confident
> about performance, NFS is another choice. " to me shows that he
> really, really doesn't know what he is talking about.
>
> A quick google findshttp://docs.hp.com/en/8988/ASM-SGeRAC-tk.pdfhttp://download-west.oracle.com/docs/html/B10812_06/appendix_b.htmhttp://www.oracle.com/technology/deploy/performance/pdf/TWP_Oracle_HP...
> etc.
>
> Some of Bob's other posts have made some here think if there is any
> ambiguity to Bob's post, it should be skewed against him.
>
> jg
> --
> @home.com is bogus.
> "This all worked fine for years on our 32-bit box with 1.5gb SGA. Now
> on a 64-bit box with 16gb SGA it can't seem to walk and chew gum at
> the same time." - Don Seiler

And I think that last attitude you describe is plain daft.

Because in rushing to trash Bob, some here have rather overlooked the OP's earlier piece of speculation about ASM making "migration" easier.

I've seen Bob argue about the BCHR in the face of all evidence and trash some pretty decent people prepared to reason with him on the point whilst doing so. I hold no candle for Bob, therefore. I do hold candles for OPs, however.

As it happens, I personally think that raw on Linux **is** much simpler to implement than OCFS2 (how simple can unformatted partitions get?! Meanwhile, OCFS2 requires kernel modules that have to match your kernel precisely, lots of fiddling around, and if you're lucky, it will work first time. Even ASM requires you to configure raw first and then do extra stuff, so by definition it cannot be simpler to implement than raw!

But all of that is only 'easy' in terms of initial setup. You lose one hell of a lot of subsequent flexibility, of course... and that's reason enough to put ASM back in the frame, big time. But there again, that sort of subtle point-making, give-and-take gets tossed out with the rush to denounce Bob, too.

Bob might be a plonker, but matters of substantive technical fact raised by OPs still deserve proper explanation rather than mere assertion. Received on Mon Sep 24 2007 - 18:18:49 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US