Re: ASM for single-instance 11g db server?

From: Mladen Gogala <mgogala_at_no.address.invalid>
Date: Tue, 5 Apr 2011 11:29:35 +0000 (UTC)
Message-ID: <ineuev$u0u$>

On Mon, 04 Apr 2011 20:46:06 -0700, onedbguru wrote:

> I would disagree with your limited knowledge

My knowledge is limited, I have no more thant 5 years of ASM experience and numerous installations. You, however, are rude and unnecessarily personal. We are professionals, remember?

> and inaccurate assessment

That would require a proof.

> of ASM and it's other features such as ACFS - especially in 11gR2. I am
> a STRONG proponent of using ASM for everything I can... and that
> includes OS Files using ASM/ACFS

ACFS on version 10g? ACFS on RH 4.x?

> think of it as a volume manager that
> not only works on a single node, but across an entire cluster.

As I've said before, ASM is good for RAC. And I know well what ASM is and what to think of it.

> A year or
> so ago, I saw it used for the middle-tier Weblogic servers where OS
> files were accessible by any node in the cluster.

For JBoss and Tomcat too?

> With EVERY database I
> have migrated to ASM (both RAC and Single-instance) I gained a minimum
> of 7% but more often closer to 13% performance improvement.

Such claim would require an independent confirmation.

> That
> includes tiny databases (<100G) as well as ELDB's (Extremely Large DB in
> the 100's of TB range - both clustered and non- clustered)

I don't have those, my largest DB is 3TB, and that is RAC. Single instance databases are, without exception, on a file system.

> BTW - I NEVER propose the waste of spindles doing RAID10 on a SAN array.
> With modern SAN storage, having the many GB of cache at the storage
> array makes any perceived write performance of RAID5 a moot point. When
> you manage 100's of TB of storage, mirroring is a massive waste and
> still does not perform any better. One of the additional features - if
> you really need 1) long distance clusters or 2) redundant storage, you
> can use ASM's FAILURE GROUPS - where you can have mirrored DISKGROUPS.
> Works great!!

Now, this is a radical approach, if I ever saw one. From my limited experience with RAID5, I have no desire to try that one ever again. Unless I hear that Mogens Norgaard or Cary Millsap are recommending RAID5, I am unlikely to ever try that one again. You are, after all, talking to a BAARF member.

> With standard file systems, each file system only gets one read and one
> write FIFO buffer for moving stuff to/from memory. When you have many
> smaller LUNS in ASM, the parallelism gives a much superior performance.

You've been talking to Oracle pre-sales support, haven't you? This doesn't sound right. The kernel FIFO buffer is not a bottleneck with file systems. Usually, disks are the bottleneck. Memory can occasionally be even faster than disks.


> Oracle just announced a new product called CloudFS. Guess what it is
> comprised of?? Oracle Clusterware+ASM+ACFS.

Yeah, Oracle has always been good with bombastic names. I distinctly remember them announcing Network Computer and Oracle Appliance. Can you remember how that ended?

> And the performance of
> ASM+ACFS is significantly faster - especially READS and DELETEs.. On
> your Linux (or any other UNIX for that matter) Try doing an "rm -FR
> somedir" where "somedir" has more than 300GB in hundreds of files - and
> tell me how long it took? With ACFS the removal of the pointers is
> instantaneous.

Not that I don't believe you, but the first paragraph of your post shows a clouded judgement. Doing benchmarks with rm -rf * is not exactly what I have in mind for testing. I will need things like tar, cpio and other stuff.

> As for compression - if the need is for performance - quit being so
> stingy with the disk space and by what you need, not what you can "get
> away with". As they have said for years now, "Disks are cheap". When
> you do TB sized databases compressing/uncompressing is a ludicrous
> configuration.

The paragraph about 100% compression with "rm" in my post was a joke. I thought that this was clear. As for disks, disks are cheap, as long as someone else is buying them.

> I would also add that using ASM for non-RAC is very much worth it. When
> your db gets to the point that it needs RAC, then it will already be in
> ASM. And with RAC if you need to move to new systems, you just add the
> new hardware to the cluster and shutdown the old nodes and you keep
> going.

That wording reminds of an episode in which Wylie Coyottee buys "earthquake pills". Works great, most of the time. I have been adding nodes to cluster and removing them from cluster. I do recommend ASM for RAC, remember? I like RAC, but there are non-technical issues, like RAC licenses. Disks are cheap. Oracle licenses are not.

> Works great, last a long time...

May the force be with you.

Received on Tue Apr 05 2011 - 06:29:35 CDT

Original text of this message