Re: ASM for single-instance 11g db server?
Date: Tue, 5 Apr 2011 11:29:35 +0000 (UTC)
Message-ID: <ineuev$u0u$6_at_solani.org>
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.
-- http://mgogala.byethost5.comReceived on Tue Apr 05 2011 - 06:29:35 CDT