From: kathy duret <>
Date: Thu, 16 Oct 2008 11:00:57 -0700 (PDT)
Message-ID: <>

ASM does take some getting used to that is for sure.

ASM is good for RAC and EBS (non RAC) as it gives you the performance close to RAW.

I like it better than Veritas clustered file system.

ASM is supposed to be easier to manage in 11G and fully integrated by 12G. 

I haven't played with it in 11G yet. 


  • On Thu, 10/16/08, Bradd Piontek <> wrote:

From: Bradd Piontek <> Subject: Re: ASM
Cc: "ORACLE-L" <>
Date: Thursday, October 16, 2008, 11:44 AM

I should preface this by saying that I have 1) used oracle clusterware in a linux RAC environment ( and 2) used Sun Cluster in a non-RAC, cold-failover ( environment.

From what I've seen, Oracle Clusterware is rock solid and easy to use when it is managing the Oracle stack. I'm also fairly positive that in a Sun Cluster RAC (10g >) environment, you'd have to have Oracle Clusterware installed anyway.I find the Oracle Clusterware to be easy to install, configure and manage over time. I didn't find there was a huge learning curve (same goes for ASM *shrug*). The commands are very similar to other oracle command line utilities. I've done very little (other than training) on how to use Oracle Clusterware to manage non Oracle resources. While it is possible, and there are examples, I can't compare how much coding is required as compared to Generic SuN Cluster resources.

Sun Cluster is a different story. It does have some nice (add-on) agents you can get for Oracle Database resources (the cluster software is free, support is not). however, in our non-RAC, cold-failover environment, I don't like some of the limitation/constraints it imposes. The first being a separate listener for every database being managed. Probably just personal preference on my part to have one shared listener. If you are monitoring via Grid Control, installing agents gets to be a bit messy as you need one agent for each host in the cluster, and then an additional agent (which is a bit interesting to install) for each database resource in the cluster that can fail over. (again, this is non RAC).

Bradd Piontek
  "Next to doing a good job yourself,
        the greatest joy is in having someone
        else do a first-class job under your  
 -- William Feather

On Thu, Oct 16, 2008 at 10:58 AM, Charles Schultz <> wrote:

On the flip side, we like our SA's. However, we are lacking in clustered experience (in any group). We have read whitepapers from both Sun and Oracle saying that their cluster stack is better than the other. What about real world experiences? Has anyone used both and have a somewhat objective comparison?

Oracle certainly picked a controversial direction with ASM. =) I still do not understand how Oracle has provided a really cool with ASM that is horribly lacking in friendliness and versatility.

On Thu, Oct 16, 2008 at 10:39 AM, Bort, Guillermo <> wrote:



Now against that, and in addition to Jared's points. I'd ask why consider a storage solution that only works for Oracle files (and even then not all Oracle files. I keep other files on my servers you know. Including stuff you'd expect to be there like alert.logs, cron scripts and so on.


ASM is designed as a CLUSTER FILESYSTEM, that's why it only supports files that *need* to be shared across all nodes. Alerts, cronts, etc are instance-dependant, so you only need them in the local server. Also, if you want a 'traditional' cluster filesystem, you can always use OCFS, although I wouldn't recommend it to anyone I don't utterly hate… :P

I've had experiences with veritas cluster filesystem not working for RAC. Really, in 10g+ ASM is the best way to go… and in 9i RAC, I'd go with raw devices instead of any cluster filesystem.

I'm a DBA and I have little but contempt for SAs (the ones I personally know, anyway), so I don't really care that they don't like ASM… :P

I'd like ASM to work for OCR and VOTING, but that is a contradiction by design.


Guillermo Alan Bort
DBA / DBA Main Team

EDS, an HP company




Charles Schultz

Received on Thu Oct 16 2008 - 13:00:57 CDT

Original text of this message