Re: About parallel server

Some OPS-capable platforms (Tru64? VAX?) already allow "cooked" files for OPS. Oracle9i will support files for OPS only on certain supported cluster file systems. Veritos has been explicitly mentioned and Veritos people say their cluster file system for parallel server will be available by the time 9i comes out. (Veritos cluster filesystems are already available, but not with OPS support). I have done 7.3 - 8.1.7 OPS on Solaris and AIX. All required raw devices for all control files, redo logs, and datafiles.

(setq rantmode ON)

Raw devices vs files seems to be a religious issue. I don't know why raw devices get such a bad rap anyway, but it seems most Oracle DBAs don't want to deal with them. In the "old days", raws were real pain - backups required dd instead of cpio/tar, creating raws manually was something of a chore, etc. However, today most backup utilities (e.g. rman, Veritos NetBackup, etc.) really don't care about raw vs filesystem. With logical volume managers, creating raw devices is much easier also. A common complaint is autoextend, but you can actually create, for example, a 2000 MB raw device and create a 500 MB datafile within it and let it autoextend to the end of the raw device. My particular "religion" on this issue is that I would rather have a number of "smaller" datafiles than one large datafile anyway. Granted, moving datafiles around to redistribute I/O between disks or stripe sets is more work, but with good design and physical layout practices, it isn't that bad. I really don't want dozens of distinct sizes for datafiles anyway. A "few" distinct sizes should do and will be a lot more flexible - on raws or on filesystems. I usually build dev and test databases on filesystems and most production databases on raw. Especially anything with a high write to read ratio.

Raws also bring a number of advantages that are rarely mentioned. In addition to the often espoused and perhaps somewhat overrated performance considerations, one can't easily "rm" a raw device or accidentally "cp" some other file over one! Many OSs support async I/O on raws, but not on filesystems. If you create raws as contiguous space and expand into it as the datafile grows, it stays contiguous. On filesystems, autoextend often (usually) results in file fragmentation within the filesystem. In my experience, raw datafiles tend to become corrupt MUCH less often than filesystem datafiles. Wasn't there a discussion here recently about "peculiarities" with Quick IO and sparse files (usually TEMP)? It isn't a problem with raws! After a large database server crash, fsck can take forever on UFS, but with a raw device database, its back very fast. (JFS/VxFS/... don't have this same problem though - they have others...). Ad infinitum.

I think the real issue is that, to not be a maintenance or performance nightmare, a database built on raw devices requires more upfront planning - a better knowledge of I/O patterns, growth trends, etc. and more thorough performance testing and tuning in laying out the database. Personally, given the option, I would rather do this up front than fight the problems later and be constantly shuffling datafiles around to compensate for less up front planning anyway.

OPS has similar issues. In spite of the "propaganda", I'll wager that even 9i RAC will be much less of a pain/problem with a carefully considered OPS (oops! RAC) implementation than with just throwing in a pile of nodes and randomly splattering transactions across them. In previous versions, including 8i, proper planning for an OPS implementation, at least for OLTP, was critical. OPS and raw devices seem to require basically the same (demented? impractical?) mentality and practices - "an ounce of prevention is worth a metric ton of cure".

(setq rantmode OFF)

-Don Granaman
[certifiable OraSaurus]

• Original Message ----- To: "Multiple recipients of list ORACLE-L" <ORACLE-L_at_fatcity.com> Sent: Thursday, May 31, 2001 12:22 PM

> I have heard rumors that OPS on 9i will allow you to use cooked files.
>
> User group meeting next week, with a presentation on 9i new features.....
> I'll ask
>
> Rachel
>
>
> >From: "Adams, Matthew (GEA, 088130)" <MATT.ADAMS_at_APPL.GE.COM>
> >Reply-To: ORACLE-L_at_fatcity.com
> >To: Multiple recipients of list ORACLE-L <ORACLE-L_at_fatcity.com>
> >Subject: RE: About parallel server
> >Date: Thu, 31 May 2001 06:06:38 -0800
> >
> >Dick,
> >
> > What are you using for your source for this information?
> >This does not jibe with other things I have read.
> >If your not going to use a shared raw device for
> >the online redo logs, how can one instance to instance recovery
> >for another instance that fails?
> >
> >----
> >R. Matt Adams - GE Appliances - matt.adams_at_appl.ge.com
> > Meddle not in the affairs of troff,
> > for it is subtle and quick to anger.
> >
> >
> > > --> Data files yes, redo and control files can be on cooked
> > > file system.
>
> _________________________________________________________________
> Get your FREE download of MSN Explorer at http://explorer.msn.com
>
> --
> Please see the official ORACLE-L FAQ: http://www.orafaq.com
> --
> Author: Rachel Carmichael
> INET: carmichr_at_hotmail.com
>
> Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
> San Diego, California -- Public Internet access / Mailing Lists
> --------------------------------------------------------------------
> To REMOVE yourself from this mailing list, send an E-Mail message
> to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
> the message BODY, include a line containing: UNSUB ORACLE-L
> (or the name of mailing list you want to be removed from). You may
> also send the HELP command for other information (like subscribing).

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.com
-- 
Author: Don Granaman
  INET: granaman_at_home.com

Fat City Network Services    -- (858) 538-5051  FAX: (858) 538-5051
San Diego, California        -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).