RE: The BIG picture - RE: Raw Devices v.s. File System

From: Steve Orr <sorr_at_arzoo.com>
Date: Wed, 12 Jul 2000 15:57:52 -0700
Message-Id: <10556.111900@fatcity.com>

It seems like Oracle is schizophrenic when you read the Oracle docs on this topic. On the one hand they say you get better performance with raw so use it; while on the other hand they say it's too hard to administer so don't use it.

Is it really that hard? To me the operative question is, "can YOU, yeah YOU, administer the database on raw devices?" When I was confronted with THIS question I decided to answer it by creating a test database and trying it out. After getting the hang of the volume manager (HPUX) and symbolic links, creating the database was a snap. Having a good volume manager is key. RMAN was great for backups but I practiced moving things around with dd too. I used standard sizes of 128M and 1G.

I studied Note 29676.1 on Metalink to compare my experience with what Oracle said the "disadvantages" were. I concluded that the "concerns" were either bogus or non-issues. Moving datafiles was not a problem but also not a likely task on RAID0+1. Likewise, capacity planning was more a function of the RAID config, not a raw vs. cooked concern. Pre-planning and using standard datafile sizes solved the flexibility issue. Adhering to OFA is a non-issue because Oracle shows how to properly use symbolic links. So what's the big deal? In the end I found that there really weren't any disadvantages or concerns with going raw. And my "testimony" is that I'm not really a UNIX guru.

Below is a paste from the Metalink document in question:

"Making the decision to use raw devices:" Note:29676.1. "The performance advantages of going raw are outweighed at most sites by the following disadvantages:

o Harder Configuration Planning.

Clients with small databases usually do not have the luxury of choosing

        from a sufficient number of well-sized raw device sections.  Disk
        sections usually come in odd sizes that do not lend themselves to
the
        implementation of a good database architecture.  Even with the
flexible
        section sizing of recent releases of System V, the DBA should make
all
        data files the same size in order to use load balancing techniques
as
        experience with the system accumulates.

     o  Harder Configuration Tuning.

        Upon finding that a particular disk drive is "hot" and that
performance
        would benefit from movement of an ORACLE data file from that drive
to
        some other, it is likely that no acceptably sized section exists on
the
        "cool" drive.  Moving data files around, a simple and attractive
option
        in a UNIX filesystem environment, is potentially impossible with raw
        devices.

     o  Harder Daily Administration.

        The administrator must use more complicated UNIX tools to monitor
and
        administer raw devices than those available for maintaining
        UNIX filesystems.  Notably, the DBA loses most of the power and
        simplicity of the ORACLE data storage portion of the OFA standard
        [OFA].  The complexity can be minimized, but only with extra

effort."

Here's a couple more Metalink notes to consider: - 20 questions on raw devices: Note:37914.1 - How to implement raw devices: Note:23037.1

So why get off to a slow start by avoiding raw when it's easy enough to implement? Tuning SQL queries after database creation is relatively easy compared to recreating the database for better performance. And going raw is not that hard so there's no need to avoid it if you don't have something like a Veritas file system. Go raw but keep your clothes on.

IMHO,
Steve Orr

Practice does not make perfect... Perfect practice makes perfect!

-----Original Message-----
From: root_at_fatcity.com [mailto:root_at_fatcity.com]On Behalf Of sean.hull_at_pobox.com
Sent: Wednesday, July 12, 2000 2:57 PM
To: Multiple recipients of list ORACLE-L Subject: The BIG picture - RE: Raw Devices v.s. File System

On Wed, 12 Jul 2000, Gaja Krishna Vaidyanatha wrote:

> Given that the performance difference between these advanced
> fileystems and Raw is not that much, it really begs the issue as
> to why one would want to give up the benefits of a filesystem.

I think this derives from whether one can paint with a big brush so to speak, or if one gets stuck in the details. Tuning large complex computing systems, like Unix systems running Oracle, often requires one to be able to look at things from a "birds eye" perspective, and see the big picture. When you do this you realize that every little ounce of performance isn't what you're after, but the orders-of-magnitude gains. You get these from:

o using advanced filesystems over traditional buffered filesystems o tuning bad SQL queries
o making sure I/O is distributed across enough disks o making sure you have enough memory that you're not swapping

To name just a few. There are often incremental gains you can get from doing a VERY LOT OF EXTRA work, which are not worth it cost-wise, and Received on Wed Jul 12 2000 - 17:57:52 CDT