Re: Why I don't like ASM
Date: Mon, 27 Jan 2014 16:32:17 +0000
Message-ID: <CAKA5CbK6wt8GFAkxvb7UXQu5fODiP1XVXbgSqFWkSAV9zPyi4A_at_mail.gmail.com>
From my point of view it's the right tool for the right job. Supporting number of Oracle databases on HP-UX it wasn't my favorite time when I had to create another datafile on RAC using Shared LVM. Bring one of the nodes, change the volume group mode, add logical volume, export, import and so on. CIFS wasn't an option back then because of money it costs. Also got two horror stories on linux with a traditional filesystems - on ext3 the journal was dropped and after a restart to find out all the files were moved to lost+found. Another one was 5TB ext3 fs format by default - it was OK before they had to reboot it after 180 days, the fsck took several hours to complete.
ASM gives you flexibility - either when you want to add or remove disk it happens online. Most useful when you have to migrate you data from one storage to another or simply change the disk characteristics. The only problem I found so far is if you use any kind of snapshot technology on the storage to refresh your DEV/UAT/TEST environments. Actually it's not a problem of ASM itself but the naming standards - if you name your data diskgroups by default DATA next time you create snapshot of this diskgroup on the storage and present it to another server. It is obvious it won't work if your target server already has a diskgroup DATA. Thus if you intend to use similar technology think of the naming standards for the ASM diskgroups. But still it's another reason why I like it - the headers are kept on the ASM disks, gives you the option to reattach the disks to another similar server.
Regards,
Sve
On Mon, Jan 27, 2014 at 3:54 PM, Uzzell, Stephan <SUzzell_at_micros.com> wrote:
> I would add that it certainly makes database growth easier... For RAC,
> using OCFS, and having datafiles on H:, I:, J:, K:, &c. as the database
> grows - not so hot. For non-RAC, using NTFS - same problem. Give me ASM
> where I can just throw more disks into the diskgroup - one less thing to
> worry about.
>
>
>
> *Stephan Uzzell*
>
>
>
> *From:* oracle-l-bounce_at_freelists.org [mailto:
> oracle-l-bounce_at_freelists.org] *On Behalf Of *Samuel Guiņales Cristobal
> *Sent:* Monday, 27 January, 2014 10:50
> *To:* ganstadba_at_hotmail.com
> *Cc:* oracle-l_at_freelists.org
>
> *Subject:* Re: Why I don't like ASM
>
>
>
> More simple reason, with time, asm has become in standard, build in oracle
> package with RAC, is easier to manage than other solutions, cheaper,etc..
>
>
>
> Regards
>
> ---
> Samuel G. Cristobal <samuel.guinales_at_gmail.com>
> OCP10g,11g
> Senior Oracle Database System Engineer
> FUJITSU
>
>
>
> On 24 January 2014 18:46, Michael McMullen <ganstadba_at_hotmail.com> wrote:
>
> the simplest reason I have for going with ASM is it's now baked into
> everything Oracle does. Docs all kind of assume ASM is being used, oracle
> appliances are using ASM. So I think as a DBA you need to know ASM. You can
> choose not to use it but you should have practical experience.
> It's also kind of an easy intro to Grid if you use it on standalone db's.
> You get familiar with the crsctl commands, has, terminology of Grid etc.
>
> ------------------------------
>
> Date: Fri, 24 Jan 2014 00:17:43 -0600
> Subject: Re: Why I don't like ASM
> From: justin_at_n0de.ws
> To: oracle_at_1001111.com
> CC: oracle-l_at_freelists.org
>
>
>
> Where I'm at the majority of ASM installs are on RAC. We have some
> stand-alone systems using ASM but that is generally because the customer
> wanted it. Like anything else there are benefits and drawbacks.
>
>
>
> The biggest drawback that I can think of is, as you said, added
> complexities and dependencies. Patching, especially, becomes more
> complicated.
>
>
>
> From an advantages perspective, I find that using ASM along with
> enterprise hardware can give you added flexibility. For instance, if a
> customer needs to migrate to faster spindles you can present the new LUNs
> to the nodes/server, and then add them to the diskgroup and drop the old
> LUNs seamlessly. I also like that it can all be managed from the Oracle
> tool-set, which means you'll have a generally similar experience across
> platforms. From what I've read there's also less I/O overhead when
> comparing ASM to a filesystem, but I'm sure that's arguable and would
> depend on the file system being used.
>
>
>
>
>
>
>
>
>
-- http://www.freelists.org/webpage/oracle-lReceived on Mon Jan 27 2014 - 17:32:17 CET