RE: ASM versus Filesystems

From: Crisler, Jon <Jon.Crisler_at_usi.com>
Date: Sat, 6 Mar 2010 10:54:57 -0500
Message-ID: <56211FD5795F8346A0719FEBC0DB0675062051DF_at_mds3aex08.USIEXCHANGE.COM>

You have some valid points but I want to make a few clarifications:  

1. Sure you can backup to FRA, but if your tape backup system is not integrated with RMAN it cannot backup directly to your tape system. There are many reasons why one would not integrate your tape backup system with RMAN, usually due to performance and cost. Obviously it is better overall to have tape-RMAN integration but sometimes you have to do without, hence the required filesystem for RMAN backup.
2. Snapshot- many vendors claim they support snapshot technology with ASM, but our testing has revealed situations where it routinely fails; we have all the major vendors in our labs and in production, and none of them work in all situations. Netapp probably has the best support overall. A classic example is having to mount an ASM diskgroup under Unix to another server because the first server died- for whatever reason this is unreliable across many vendors, resulting in corrupted tablespaces. I don't want to name those vendors because I don't want to bash anybody. We have seen the failures occur under RH5, AIX and Solaris so it does not appear to be limited to certain OS or hardware.
3. Often overlooked is a FTP option for ASM where if you need to extract datafiles etc. you can implement the FTP facility and get to datafiles and write them to a filesystem. I personally have not tried it but it is documented. Obviously this is not meant to expose the datafiles to the public, rather it is a way to move the files around.

Adding new luns to diskgroups, the removing the old luns from the diskgroup is a great way to migrate data from one disk array to another with little or no downtime. Dealing with OCR and voting disks is more complicated though- for this reason I recommend if you are implementing RAC to have a minimum of two OCR and two voting disks on different LUNs
(probably its Oracle's best practice as well).
 

From: Thomas Roach [mailto:troach_at_gmail.com] Sent: Friday, March 05, 2010 9:51 PM
To: Crisler, Jon
Cc: po04541_at_yahoo.com; Oracle L
Subject: Re: ASM versus Filesystems  

Hi,  

I would like to add a couple of things. You can still do your backups to an ASM diskgroup. In our case, we backup to FRA and then backup our FRA to Tape. When we restore from tape, it will restore directly to the DB from tape if the backup is not in FRA.  

What we do is we keep at least 1 full backup in FRA, plus all incrementals for 1 week, and keep anything over that on tape.  

Also, you can have disk snapshot facilities, but you need to put your database in backup mode (and test your backups). The reason you need to do this is because database operations are still happening and blocks are being written to disk. This is so that blocks that are touched for the first time during the backup window are written to the redo stream since a block can be corrupted while it is being backed up (Oracle is in the middle of a write operation and only half the new data gets written during a snapshot of that block). The benefit RMAN has is that it can check a block for corruption where snapshots are unaware of what is and isn't a valid oracle block, it just backs up the data.  

ASM is very powerful and scalable. I was able to add luns and remove luns (rebalancing them into ASM) without having to take my database down. Also, only use ASM with block devices (scsi, iscsi etc...) and not on top of a filesystem or NFS as the extra layers don't gain you anything. If you do use disk based snapshots then if you add luns/remove luns, make sure you update what you snapshot. If you miss just one disk, you are in deep trouble.  

I also bought the Oracle Press Book by Nitin Vengurlekar (spelling) which is a very good book.  

Good Luck!  

Tom

On Fri, Mar 5, 2010 at 9:09 PM, Crisler, Jon <Jon.Crisler_at_usi.com> wrote:

The only bad thing about ASM is the learning curve; honestly I think it was fear of the unknown that kept me away from ASM for so long. Once you jump in and get comfortable with it you too will wonder why you stayed away.

If you do backups to disk that are later picked up by a tape program, you will still need a filesystem to hold the backup, or if you use some sort of disk snapshot facility it may not support ASM, but those are the only drawbacks I am aware of. It does require one to get more familier with RMAN. Compared with OCFS2 or other clustering filesystems it seems to be quite reliable, and if you are using it with RAC then you save a bundle on license cost for other clustering filesystem software
(like GFS, Veritas etc.).
 

Jon - aka "Capt Aubrey"  

From: oracle-l-bounce_at_freelists.org
[mailto:oracle-l-bounce_at_freelists.org] On Behalf Of patrick obrien Sent: Friday, March 05, 2010 5:45 PM
To: Oracle L
Subject: ASM versus Filesystems  

Oracle Admins,

I've been an AIX Admin for years, I'm a junior Oracle DBA and I apologize if the ASM Topic has come up lately. As an AIX Admin, using filesystems seems the best option for me.

Reading up on Oracle's ASM technology, it looks like this could be a great option, primarily for performance reasons. Oracle would then own more real estate, so it can use its tools to better tune the entire system. Its almost too good to be true.

But what are the caveats?

AIX Filesystems offer me control on filesystems/directory sizes, increased performance and systems control. Filesystems are nice when managing backups too. With the advent of the NAS/SAN, maybe I can just hand it all over to Oracle.

Any body not like ASM out there?

Thank you,
Patrick.       

-- 
Thomas Roach
813-404-6066
troach_at_gmail.com


--
http://www.freelists.org/webpage/oracle-l

Received on Sat Mar 06 2010 - 09:54:57 CST