Re: ASM

From: Bradd Piontek <piontekdd_at_gmail.com>
Date: Thu, 16 Oct 2008 11:44:05 -0500
Message-ID: <e9569ef30810160944q482ca38dvdb999cf7bc4b6887@mail.gmail.com>


I should preface this by saying that I have 1) used oracle clusterware in a linux RAC environment (10.2.0.3) and 2) used Sun Cluster in a non-RAC, cold-failover (10.2.0.2) 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
        direction."
  • William Feather

On Thu, Oct 16, 2008 at 10:58 AM, Charles Schultz <sacrophyte_at_gmail.com>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 <guillermo.bort_at_eds.com>wrote:
>
>> <QUOTE>
>>
>>
>>
>> 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.
>>
>>
>>
>> </QUOTE>
>>
>>
>>
>> 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.
>>
>>
>>
>> Regards
>>
>>
>>
>> *Guillermo Alan Bort*
>>
>> DBA / DBA Main Team
>>
>>
>>
>> *EDS*, an HP company
>>
>>
>>
>>
>>
>>
>>
>>
>>
>
>
>
> --
> Charles Schultz
>

--
http://www.freelists.org/webpage/oracle-l
Received on Thu Oct 16 2008 - 11:44:05 CDT

Original text of this message