Re: Cluster File System Versus ASM for RAC Deployment in Production?... Pros & Cons
- From: Dan Norris <dannorris@xxxxxxxxxxxxx>
- To: Matthew Zito <mzito@xxxxxxxxxxx>, VIVEK_SHARMA@xxxxxxxxxxx, oracle-l@xxxxxxxxxxxxx
- Date: Thu, 6 Dec 2007 06:34:46 -0800 (PST)
>> However, OCFS2 has no capability
for growing filesystems, creating situations where using OCFS2 for
datafiles means increasing the number of mounts over time, which gets
messy.
That's incorrect. "tunefs.ocfs2 -S /dev/sde1" will grow the FS to the size of
the partition where it resides. Just tested it this week:
[root@ch-srlxdb01 ~]#
tunefs.ocfs2 -S /dev/sde1
tunefs.ocfs2 1.2.7
Changing volume size from
1309649 blocks to 1834541 blocks
Proceed (y/N): y
Resized volume
Wrote Superblock
----- Original Message ----
From: Matthew Zito <mzito@xxxxxxxxxxx>
To: dannorris@xxxxxxxxxxxxx; VIVEK_SHARMA@xxxxxxxxxxx; oracle-l@xxxxxxxxxxxxx
Sent: Thursday, December 6, 2007 8:29:24 AM
Subject: RE: Cluster File System Versus ASM for RAC Deployment in
Production?... Pros & Cons
I always recommend using both ASM and a CFS, where appropriate. For
example, on Linux systems, where there is a free, Oracle-supported CFS
(OCFS2), I recommend making a small OCFS2 filesystem (or two) for storage
of OCR and voting files. Then, make the primary datafile/index/log
storage on ASM. Optionally, they can then have a large dump or backup
filesystem that is OCFS2, or NFS - but I always recommend keeping an
archive location outside of ASM, so if the ASM instance won't start up, you
can at least get to your archive logs, and presumably you're doing
backups or a standby database somewhere.
The reason for using both ASM and CFS on Linux is because dealing with
multiple block devices for the various OCR and Voting devices is
annoying and complex, and typically you'll end up wasting a lot of disk space
(i.e. allocating an 8GB lun for a 100MB ocr device). By using a
clustered file system, you can put multiple objects on the one disk, and if
necessary, store other things there. However, OCFS2 has no capability
for growing filesystems, creating situations where using OCFS2 for
datafiles means increasing the number of mounts over time, which gets
messy. ASM solves that problem for you by doing very basic striping.
Thanks,
Matt
--
Matthew Zito
Chief Scientist
GridApp Systems
P: 646-452-4090
mzito@xxxxxxxxxxx
http://www.gridapp.com
-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx on behalf of Dan Norris
Sent: Thu 12/6/2007 7:51 AM
To: VIVEK_SHARMA@xxxxxxxxxxx; oracle-l@xxxxxxxxxxxxx
Subject: Re: Cluster File System Versus ASM for RAC Deployment in
Production?... Pros & Cons
Personally, I'd choose ASM and recommend it to all my customers. This
is partly because: 1) Oracle recommends it, 2) if Oracle recommends
something, they generally support it better than things they don't
recommend, 3) it doesn't cost extra money, and 4) I think ASM is a fine product
that does its job well (admittedly better in 11g than 10g, but that's
not your question).
I think that using a CFS requires training for system admins while ASM
would also require training, but possibly for the DBAs instead of the
sysadmins. Typically, I still see ASM being managed by DBAs even though
it really isn't a database. Many companies have the DBAs manage
anything with the word Oracle stamped on it.
For docs or links, see otn.oracle.com/asm.
Dan
----- Original Message ----
From: VIVEK_SHARMA <VIVEK_SHARMA@xxxxxxxxxxx>
To: "oracle-l@xxxxxxxxxxxxx" <oracle-l@xxxxxxxxxxxxx>
Sent: Wednesday, December 5, 2007 9:08:21 PM
Subject: RE: Cluster File System Versus ASM for RAC Deployment in
Production?... Pros & Cons
Other related posts:
