RE: OFA myths was Re: BAARF

Steve,

Thank you. I am grateful that someone else shrugs too.

I still get a lot of feedback about the OFA. Almost every conference I go to, someone forgives me for writing the OFA Standard. And I leave not knowing for sure where things went wrong.

A few weeks ago, one of the Oracle-L threads went down the trail of how the OFA requires that you separate index and heap segments on different disks. Bracing myself for embarrassment, I actually took the time to go back and read the OFA Standard document again, and much to my relief, I had not written that. (I did say that they should be stored in separate tablespaces, and I still believe that the reasons I proposed for that recommendation are legitimate. But where tablespaces should go on disk is a function of your specific operational metrics, not somebody's standards document.)

There have been a lot of "OFA" documents published by various parties since my OFA document. I haven't read them all. Best I can figure is that some of these authors have been more strict in their interpretation of what I had tried to say. I tried to be *very* careful in my specification so that the document wouldn't become irrelevant with technology changes. I of course wouldn't have predicted all the technology changes that have occurred since 1995, but I phrased things as carefully as I could to allow for changes.

For example, I never said you have to name mount points "/u[0-9][0-9]". I offered that as a good "OFA compliant" solution, but the OFA requirement for mount point naming is very open-ended:

"Name all mount points that will hold site-specific data to match the pattern /pm, where p is a strong constant chosen not to misrepresent the contents of any mount point, and m is a unique fixed-length key that distinguishes one mount point from another."

Granted, this doesn't provide for people naming their mount points after planets or Muppets or mountain peaks, but I still believe that it's a good idea to choose mount point names from a domain that can be unambiguously identified with a simple regular expression.

And so on...

Cary Millsap
Hotsos Enterprises, Ltd.
http://www.hotsos.com

Upcoming events:

- Performance Diagnosis 101: 10/28 Phoenix, 11/19 Sydney
- Hotsos Symposium 2004: March 7-10 Dallas
- Visit www.hotsos.com for schedule details...

-----Original Message-----
Steve Rospo
Sent: Thursday, September 25, 2003 5:10 PM To: Multiple recipients of list ORACLE-L

I'd like to get rid of the myth that OFA really states all that much about
what goes in what tablespace etc. I've got a copy of the Cary's OFA paper
entitled "The OFA Standard - Oracle7 for Open Systems" dated Sept 24, 1995. (Happy belated birthday OFA!) At the end of paper there's a summary
of the requirements and the recommendations that make up OFA. The CLOSEST
the OFA comes to specifying table/index separation are

"#7 Separate groups of segments with different lifespans, I/O request demands, and backup frequencies among different tablespaces."

-or maybe-

"#11 *IF* [emphasis mine] you can afford enough hardware that: 1) You can
guarantee that each disk drive will contain database files from exactly one application and 2) You can dedicate sufficiently many drives to each database to ensure that there will be no I/O bottleneck."

The document itself says, "The OFA Standard is a set of configuration guidelines that will give you faster, more reliable Oracle database that require less work to maintain." So every time I read that someone is putting redo here, index tablespaces here, and temp tablespaces there in order to be "OFA compliant" I kinda shrug. Obviously it's all a good idea
to separate this stuff but it's not absolutely required for OFA-ness. Essentially, OFA is just a very good way of separating Oracle code from Oracle data to make administration *much* easier. I'm sure before OFA there were plenty of places that had everything under $ORACLE_HOME/dbs and
no naming standard for datafiles. Ugh!

Now if we could only find this "Cary V. Millsap, Oracle Corporation" character so he could explain himself. ;-) '95 was a loooooong time ago.

S-

On Thu, 25 Sep 2003, Thomas Day wrote:

[snip]

> While we're at it could we blow up the OFA myth? Since you're
tablespaces
> are on datafiles that are on logical volumns that are on physical
devices
> which may contain one or many actual disks, does it really make sense
to
> worry (from a performance standpoint) about separating tables and
indexes
> into different tablespaces?

[snip]

> Maybe we will never get rid of the OFA myth.
>

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: Steve Rospo
  INET: srospo_at_watchmark.com

Fat City Network Services    -- 858-538-5051 http://www.fatcity.com
San Diego, California        -- Mailing list and web hosting services
---------------------------------------------------------------------
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.net
-- 
Author: Cary Millsap
  INET: cary.millsap_at_hotsos.com

Fat City Network Services    -- 858-538-5051 http://www.fatcity.com
San Diego, California        -- Mailing list and web hosting services
---------------------------------------------------------------------
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).