RE: ASM versus Filesystems
- From: "Crisler, Jon" <Jon.Crisler@xxxxxxx>
- To: "Thomas Roach" <troach@xxxxxxxxx>
- Date: Sat, 6 Mar 2010 10:54:57 -0500
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@xxxxxxxxx]
Sent: Friday, March 05, 2010 9:51 PM
To: Crisler, Jon
Cc: po04541@xxxxxxxxx; 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@xxxxxxx>
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@xxxxxxxxxxxxx
[mailto:oracle-l-bounce@xxxxxxxxxxxxx] 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@xxxxxxxxx
Other related posts:
