well, i asked and he answered. makes a lot of sense to me.
--
Bill "Shrek" Thater Certifiable ORACLE DBA
Telergy, Inc. thaterw_at_telergy.net
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
You gotta program like you don't need the money,
You gotta compile like you'll never get hurt,
You gotta run like there's nobody watching,
It's gotta come from the heart if you want it to work.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
one ping to rule them all, one ping to find them, one ping to bring them all, and in
the darkness bind them.
---------- Forwarded message ----------
Date: Fri, 06 Jul 2001 15:51:03 -0500
To: "Thater, William" <ThaterW_at_telergy.net>
Bill:
Back in the early 1990s, I visited one or two Oracle customers per week,
doing installations, upgrades, and system performance improvement work. Most
of the performance optimization work in those days (Oracle 6.0.26 through
6.0.36 mostly) involved figuring out a better way to distribute files across
file systems. The root cause of a *lot* of performance problems was the
implicit assumption that you should lay all your database-related files into
a single file system called 'oracle.' The Oracle documentation of the day
really didn't provide any good advice about how to distribute files onto
physical devices. The assumption people made was that keeping files in one
place was a good idea because this made them easier to manage.
When people figured out that they needed to distribute files across file
systems, they rarely had good places to put them. For example, I visited a
medium-sized law firm (which I learned, from an I.S. perspective, is really
a document-management company) that had four major UNIX file systems: /usr,
/tmp, /oracle, and /wp (where they kept all their WordPerfect files). Of
course, distributing Oracle files across file systems meant putting Oracle
files onto the /usr, /tmp, and /wp file systems, which was a gross violation
of the intent of the file system names. And, of course, putting Oracle files
in all these odd places required the DBA to modify his or her backup
programs, and so on. People had to query the database just to figure out
where all their files were (try to do this when your database is down).
These types of problems drove the idea of generically-named mount points.
>From that idea, the directory structure recommendations were the reasonably
obvious result of factorization. For example, one embeds the db_name into
all of one's database files in order to deal with all of the files of a
database as "a flock." Upon doing this, it becomes pretty apparent that the
db_name should be "factored out" of the filename, into the pathname. Thus
(abcsystem01.dbf, abctemp01.dbf, ...) becomes abc/(system01.dbf, temp01.dbf)
(or just abc/*), much like (32+16+...) becomes 16*(2+1+...). The need for
this "db_name" layer becomes apparent only when you have two or more
database on the same machine to manage, which of course, a lot of Oracle
Apps sites had (dev, test, prod, etc.). (By the way, the easier way that
Linda [below] is looking for is simply "ls -lt /*/oradata/db_name1/*". The
ability to use a single pattern to identify all of the files from a given
database was one of the most important conveniences that the OFA Standard
provided to people.)
The first OFA document I wrote was an attempt to tell the presales guys in
the Dallas Oracle office how to install demo instances of Oracle onto an HP.
I invested the nights and weekends to make it "customer consumable" because
it made me more effective as a consultant to fax the document ahead of a
consulting visit, so that I wouldn't consume client billable hours debating
the merits of generic mount-point naming with UNIX system administrators (I
lost a lot of these battles before I wrote the document).
The first published OFA document was for IOUW in Miami Beach in 1991. I
prepared the next and "final" OFA Standard document in response to the
barrage of "Do I really have to do it *exactly* this way?" questions about
the first one. This final document split the OFA Standard into two parts:
(1) a set of requirements that *everyone* must address, regardless of OS or
file naming preference; and (2) one specific way to name things that will
meet the requirements. The intent was that the requirements would stand the
test of time, and the guidelines would provide people an easy way to get
going without having to invent a bunch of things by themselves. I stopped
working on the OFA Standard back in about 1995, but many at Oracle and
beyond have taken the basic requirements and ported them into thousands of
implementations worldwide. With Ken Jacobs' (and many others') help, the OFA
Standard became an integrated part of the Oracle Installer and documentation
through Releases 7 and 8.
If you're interested in a copy of the final OFA Standard document that I
wrote at Oracle, you can find it at www.hotsos.com. Click on "Downloads" and
you can see it in our catalog. It's available free of charge, courtesy of
the paper's owner, Oracle Corporation.
Cary Millsap
Manager, Hotsos LLC
mailto:cary.millsap_at_hotsos.com
http://www.hotsos.com/
-----Original Message-----
Sent: Friday, July 06, 2001 2:21 PM
To: cary.millsap_at_hotsos.com
i made the mistake of saying it was too bad you're not on the list so you
could tell us what was on your mind when you designed it. then i asked if
anyone had your address to forward it to you. guess i got elected to ask
the
question.;-)
so what was the reason for OFA? [besides saving what little sanity i have
left.;-)]
--
Bill "Shrek" Thater Certifiable ORACLE DBA
Telergy, Inc. thaterw_at_telergy.net
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
You gotta program like you don't need the money,
You gotta compile like you'll never get hurt,
You gotta run like there's nobody watching,
It's gotta come from the heart if you want it to work.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
one ping to rule them all, one ping to find them, one ping to bring them
all, and in the darkness bind them.
---------- Forwarded message ----------
Date: Fri, 06 Jul 2001 10:13:06 -0800
Reply-To: ORACLE-L_at_fatcity.com
To: Multiple recipients of list ORACLE-L <ORACLE-L_at_fatcity.com>
This was my memory as well. I thought separating archive, redo, indexes,
data
and so on predated OFA. Also, I read through the comments pretty quickly
but I
thought Oracle discouraged the use of symbolic links for data files. I've
seen
this done without trouble but isn't there some potential error that this
might
trigger? Seems to me there was some traffic on the list for this a while
back...
Ready to be wrong,
Kip
|IMHO I think you all have got the reasons for OFA somewhat backwards. Back
in
|the older days one had one and only one version of Oracle running on a
|particular machine at one time. This made upgrading/migrating or running a
new
|version in test while the older one was still running production absolutely
|impossible or at least very difficult. The idea around OFA is that you
have one
|or more Oracle home directories off of Oracle base and all of your data
files
|elsewhere. Now when it comes time to upgrade you just shutdown, backup the
|datafile area, move a couple of init or cfg files, startup, run the scripts
|required, shutdown & backup the same directory(s) again.
|Dick Goulet
|____________________Reply Separator____________________
|Author: Tim Gardner <tgardner_at_codeHorse.com>
|Date: 7/5/2001 5:15 PM
|>Does anyone use OFA as their company standard? If so, are there any
|>complaints about it's structure? For example, the commingling of
|>different database subdirectories under a given mount point?
|>
|>e.g..
|>
|>/u02/oradata/db_name1/userdata01.dbf
|>/u02/oradata/db_name2/userdata01.dbf
|>/u03/oradata/db_name1/userdata02.dbf
|>/u03/oradata/db_name2/userdata02.dbf
|>
|>You cannot cd to a given subdirectory, ls -ltR | more to see all the
|>datafiles associated with a given database. Instead, from / you
|>have to ls -ltR | grep db_name1 to scan the full file system. Seems
|>like there should be a better way.
|>
|>Any input, pro or con, is appreciated.
|Linda,
|The point of OFA is to spread out the database over different drives
|for performance reasons. For example, you might want to separate
|indexes from data. Would what you are proposing allow for multiple
|drives?
|Tim
|--
|Please see the official ORACLE-L FAQ: http://www.orafaq.com
|--
|Author: Tim Gardner
| INET: tgardner_at_codeHorse.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:
| INET: dgoulet_at_vicr.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:
INET: Kip.Bryant_at_Vishay.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: Thater, William
INET: ThaterW_at_telergy.net
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).
Received on Fri Jul 06 2001 - 15:59:15 CDT
