Return-Path: Delivered-To: 2-oracle-l@orafaq.com Received: (qmail 14670 invoked from network); 6 Dec 2007 09:21:52 -0600 Received: from freelists-180.iquest.net (HELO turing.freelists.org) (206.53.239.180) by 69.64.49.119 with SMTP; 6 Dec 2007 09:21:52 -0600 Received: from localhost (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 52C357D2E9F; Thu, 6 Dec 2007 10:21:52 -0500 (EST) Received: from turing.freelists.org ([127.0.0.1]) by localhost (turing.freelists.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17888-04; Thu, 6 Dec 2007 10:21:52 -0500 (EST) Received: from turing (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id B65CE7D2BED; Thu, 6 Dec 2007 10:21:51 -0500 (EST) Received: with ECARTIS (v1.0.0; list oracle-l); Thu, 06 Dec 2007 09:34:55 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 21B247D41DB for ; Thu, 6 Dec 2007 09:34:55 -0500 (EST) Received: from turing.freelists.org ([127.0.0.1]) by localhost (turing.freelists.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07905-05 for ; Thu, 6 Dec 2007 09:34:55 -0500 (EST) Received: from web35411.mail.mud.yahoo.com (web35411.mail.mud.yahoo.com [66.163.179.120]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with SMTP id C44B17D42E1 for ; Thu, 6 Dec 2007 09:34:51 -0500 (EST) Received: (qmail 80741 invoked by uid 60001); 6 Dec 2007 14:34:46 -0000 X-YMail-OSG: ySzMyDYVM1lYP3W6oY.z0K4xLX9g7GsZIvmgKnhSO4usRL1MdO5sRs9tRI1_Fq8DfcmYU8ElMcbStLvRytVHLERYHKxP1fWdFZladGAK0f6l7iKc_.C_PPwt_4kgvw-- Received: from [67.90.115.78] by web35411.mail.mud.yahoo.com via HTTP; Thu, 06 Dec 2007 06:34:46 PST Date: Thu, 6 Dec 2007 06:34:46 -0800 (PST) From: Dan Norris Subject: Re: Cluster File System Versus ASM for RAC Deployment in Production?... Pros & Cons To: Matthew Zito , VIVEK_SHARMA@infosys.com, oracle-l@freelists.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-608118714-1196951686=:80738" Message-ID: <558492.80738.qm@web35411.mail.mud.yahoo.com> X-archive-position: 3745 X-ecartis-version: Ecartis v1.0.0 Sender: oracle-l-bounce@freelists.org Errors-to: oracle-l-bounce@freelists.org X-original-sender: dannorris@dannorris.com Precedence: normal Reply-to: dannorris@dannorris.com List-help: List-unsubscribe: List-software: Ecartis version 1.0.0 List-Id: oracle-l X-List-ID: oracle-l List-subscribe: List-owner: List-post: List-archive: X-list: oracle-l X-Virus-Scanned: Debian amavisd-new at localhost.localdomain --0-608118714-1196951686=:80738 Content-Type: text/plain; charset=us-ascii >> 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 To: dannorris@dannorris.com; VIVEK_SHARMA@infosys.com; oracle-l@freelists.org 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@gridapp.com http://www.gridapp.com -----Original Message----- From: oracle-l-bounce@freelists.org on behalf of Dan Norris Sent: Thu 12/6/2007 7:51 AM To: VIVEK_SHARMA@infosys.com; oracle-l@freelists.org 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 To: "oracle-l@freelists.org" Sent: Wednesday, December 5, 2007 9:08:21 PM Subject: RE: Cluster File System Versus ASM for RAC Deployment in Production?... Pros & Cons --0-608118714-1196951686=:80738 Content-Type: text/html; charset=us-ascii
>> 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@gridapp.com>
To: dannorris@dannorris.com; VIVEK_SHARMA@infosys.com; oracle-l@freelists.org
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@gridapp.com
http://www.gridapp.com



-----Original Message-----
From: oracle-l-bounce@freelists.org on behalf of Dan Norris
Sent: Thu 12/6/2007 7:51 AM
To: VIVEK_SHARMA@infosys.com; oracle-l@freelists.org
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@infosys.com>
To: "oracle-l@freelists.org" <oracle-l@freelists.org>
Sent: Wednesday, December 5, 2007 9:08:21 PM
Subject: RE: Cluster File System Versus ASM for RAC Deployment in Production?... Pros & Cons







--0-608118714-1196951686=:80738-- -- http://www.freelists.org/webpage/oracle-l