Re: Unix File System versus ROW device

In article <01bc80ff$58cd5a00$941e22cf_at_fred.sympatico.ca>, Roy Klassen <rklassen_at_pei.sympatico.ca> writes
>The advantage of using the RAW device is that it is faster because you are
>not going through the UFS cache or buffer.

        There's an exception to this - see below.
        

>The disadvantage is that the tablespaces created in the RAW volumes are
>fixed size. The only way to increase the size is to drop the raw device
>and recreate, or create another raw device for the tablespace.
>Both are a little more work.
>

        If your system supports logical volume management and you're running oracle 7.2.3 or above then you can get around this. Create your raw tablespaces on logical volumes and you can resize and reorganize the devices to your heart's content. Then, with oracle 7.2.3 and above you can resize existing datafiles without affecting the contents: to enlarge a raw tablespace just allocate more space on the logical volume and run:

ALTER DATABASE DATAFILE <filename> RESIZE <new size>

Seems to work on my site, anyway - 7.2.3 under AIX.

>I would not use the RAW devices in a Development environment bacause, the
>tablespace sizing is not stable. However, in a Production environment
>where the sizing has been done properly and performance is more of an
>issue; RAW devices is definitely the way to go.
>

        Apparently, this isn't always true. I was at a seminar on 'Very Large Databases' a few months ago, given by a guy from Oracle US who specialized in storage-related issues. He said that full table scans perform significantly less well on raw devices because they don't write to the oracle buffer cache - which normally acts as a cache for raw device access. As you're bypassing the operating system cache, this means that there's no cacheing at all on full table scans, so disk access is much less efficient. I've not observed this myself (yet), but it seems to make sense. Does anyone else have any comments?

-- 
Sam Dodsworth