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:53:45 -0800 (PST)

Sorry--I forgot to also include that I completely agree with Matt's comments 
about using ASM + a CFS--especially to support a secondary archivelog 
destination. I sometimes also use a local (non-shared) filesystem for a 
secondary archivelog destination if a CFS isn't available. Some customers don't 
like to add the additional "special" software required to support the CFS in an 
already-complex environment. 

Good comments, Matt. 

Dan

----- Original Message ----
From: Dan Norris <dannorris@xxxxxxxxxxxxx>
To: Matthew Zito <mzito@xxxxxxxxxxx>; VIVEK_SHARMA@xxxxxxxxxxx; 
oracle-l@xxxxxxxxxxxxx
Sent: Thursday, December 6, 2007 8:34:46 AM
Subject: Re: Cluster File System Versus ASM for RAC Deployment in 
Production?... Pros & Cons


>> 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









Other related posts: