Re: Filesystem Block Size ? 1K or 4K or 8K ?

From: Krishna Manoharan <krishmanoh_at_gmail.com>
Date: Wed, 15 Oct 2008 20:16:06 -0700
Message-ID: <c5d32c4d0810152016t24b43af1o1801f9ef8c3d547d@mail.gmail.com>


We did an evaluation of ASM from a tactical perspective for single instance and RAC - This is what we came up with.

  1. ASM offered good benefits for a RAC instance as we can do away with the complexities of a Cluster Filesystem. For a single instance, not so much.
  2. ASM also gave equivalent performance (if properly designed) with a Vxvm/Vxfs/ODM combination (properly designed).
  3. One advantage was reduction in initial price of the solution - ASM was at no-initial price versus Vxvm/Vxfs/ODM.
  4. However ASM required some re-thinking/re-learning concepts regarding file/space management - for DBA and SA. In a organization such as ours, there are some 50 dba's and 30 SA's with varying levels of skills supporting a large number of environments - training every one to understand ASM concepts was not practical. In an environment with a model of pool resources wherein anyone can support any environment, it becomes difficult to support.
  5. We do backups for recoverability, before patching/upgrades and also for database refreshes. ASM did not meet our requirements for these specific requirements adequately and efficiently. 2 options available to us - RMAN or Shadow Image/Flashsnap.
  6. Using RMAN daily for backup to tape/disk was not the preferred method in our environments due to size of data, host impact and time taken to do the backup. For RAC, we can dedicate a node for backup alone and do RMAN to disk and then do backup to tape over the SAN, but impact on other nodes (due to the RAC shared storage) during backup was significant. For a single instance, not feasible. Also RMAN did not make it easy to do database refreshes (prod to non-prod environments) or an entire database backup for an upgrade in a timely manner.
  7. If using ASM, a daily shadow image/flashsnap style backup coupled with instant space optimized snapshots worked for backup sake - but not easy to move it to tape, nor use this data easily for doing database refreshes.
  8. Considering the above, for a single instance, filesystem based approach was lot more simpler and easier to manage. We went with Vxvm/Vxfs/ODM and Flashsnap for backups. Restore was as simple as bringing up a parallel instance using the datafiles on the Flashsnap filesystems (restored from tape) and do a selective export of the required data. For refresh, we mounted the Flashsnap filesystems on to the Non-prod systems and copied the datafiles over the SAN. Could be completely automated and simple to manage.
  9. For RAC, ASM did have a strong argument - simpler and cleaner interface - cluster filesystems have an overhead and is messy to setup/manage. But backups/refreshes is a big sticking point - for e.g. when we have to restore and verify data (from a specific time period) for sox compliance checks. We went with Cluster Filesystem with Flashsnap for backups due to in-house available skills and the ease of backups/restores/refreshes.

Ultimately it came down to ease of support, backups/restores/refresh, flexibility and filesystems was the winner.

Thanks
Krishna Manoharan
http://dsstos.blogspot.com

On Wed, Oct 15, 2008 at 1:08 PM, Mercadante, Thomas F (LABOR) < Thomas.Mercadante_at_labor.state.ny.us> wrote:

> I'm with you Jared. Until I am shown an absolute good reason for doing
> this then I am sticking with normal file systems.
>
>
>
> ------------------------------
>
> *From:* oracle-l-bounce_at_freelists.org [mailto:
> oracle-l-bounce_at_freelists.org] *On Behalf Of *Jared Still
> *Sent:* Wednesday, October 15, 2008 3:48 PM
> *To:* dannorris_at_dannorris.com
> *Cc:* VIVEK_SHARMA_at_infosys.com; Greg Rahn; ORACLE-L
> *Subject:* Re: Filesystem Block Size ? 1K or 4K or 8K ?
>
>
>
>
>
> On Wed, Oct 15, 2008 at 6:21 AM, Dan Norris <dannorris_at_dannorris.com>
> wrote:
>
>
> If you would, please share with us your reasons to avoid ASM. Based on your
> response, I'm guessing that the reasons might include "because that's the
> way I've always done it".
>
>
>
> Personally, I don't use it as it adds more complexity to our environment.
>
> We (by which I really me 'I') don't need to add any more complexity.
>
> * Additional instance for ASM
> * file management is simpler
> * storage admins have easy direct access to see what's on disk.
>
> I'm sure there are some rebuttals to this.
>
> Let's hear 'em!
>
>
> Jared Still
> Certifiable Oracle DBA and Part Time Perl Evangelist
>
>
>

--
http://www.freelists.org/webpage/oracle-l
Received on Wed Oct 15 2008 - 22:16:06 CDT

Original text of this message