RE: what is BAARF? --- OFA

Hey Tim,

D'oh! The problem with e-mail is that it takes an hour to convey what would take 5 minutes in person... :)

While I stand by my original e-mail, I do understand that OFA was designed to do exactly what the acronym says: be optimal and flexible. My problem with it is that I do not see OFA as optimal, at least not anymore. Perhaps it's just me, but I just don't understand the reasoning of the parts of OFA I had outlined now nor 14 years ago. Maybe it's because I had much more hair 13-14 years ago (more on my head, at least, with less in other places), and the combined human caused faults/accidents over those years has caused me to be much more strict in the way I'd like to see hardware and software set up. Or perhaps it's because I cut my teeth on VMS and haven't conformed to accepted Unix practice, nor do I see a need to if an alternative can be established as being subjectively "better" (re: "/unn" mountpoints).

OK, enough of my babble. I would LOVE to see OFA updated! I won't hold my breath that any of my suggestions would be incorporated, but then again I'm just one person. I'll happily continue using a mostly-OFA setup. Except on VMS, which Oracle Corp does not conform to OFA at least thru v8.1.7. Then again, we have no more VMS... :(

BTW, wasn't dangling from a clock tower Harold Lloyd's trademark? :)

Thanks for listening to my whining,
Rich

Rich Jesse                           System/Database Administrator
rjesse_at_qtiworld.com                  Quad/Tech Inc, Sussex, WI USA

> -----Original Message-----
> From: Tim Gorman [mailto:tim_at_sagelogix.com]
> Sent: Tuesday, August 05, 2003 11:09 AM
> To: Multiple recipients of list ORACLE-L
> Subject: Re: what is BAARF? --- OFA
>
>
> Rich,
>
> The original author of OFA is an active contributor to this
> list, but I
> don't know whether there will be a response, so I thought I'd jump in.
>
> Optimal Flexible Architecture (OFA) was such a fundamental
> dose of common
> sense 13-14 years ago that it's very revolution has lost it's
> sting over the
> years. Kind of like the way that nobody finds the Marx
> Brothers movies to
> be funny anymore, because every other comedy movie
> immediately fell into the
> same pattern, causing everyone to forget that movies comedies
> previosly
> meant people bashing each other in the head and dangling from
> clock towers
> and stuff...
>
> Oracle used to ship everything under the $ORACLE_HOME
> directory, which was
> bad in so many ways it can't be counted. If I were to
> summarize OFA, it was
> recognition that at least three major sets of directory
> structures were
> needed:
>
> * software distribution
> * administrative, trace, and log files
> * database files
>
> Each had to be separated, because each gets treated
> differently. Software
> distribution would be updated and upgraded. Admin files had
> to persist
> across updates/upgrades but not be lumped in with the actual
> database. The
> actual database had to be treated differently than either
> software or admin
> files for obvious reasons.
>
> Yes, naming online redo log files with ".log" extensions is
> bad; I went to
> recommending ".rdo" extensions long ago for that reason. OFA
> isn't hung up
> on specific names, in fact the original paper specifically
> avoids suggesting
> names other than for illustration purposes. Same with the
> MTPT names...
>
> Just as with the Marx Brothers movies, imagine a world where
> OFA didn't
> exist, where the author didn't push and push and push and
> push the Oracle
> product folks to see the light and stop installing product as if every
> server was a desktop PC...
>
> Hope this helps...
>
> -Tim
>
>
> on 8/5/03 7:49 AM, Jesse, Rich at Rich.Jesse_at_qtiworld.com wrote:
>
> > Not a "taker", but I'll put in my disdain for OFA, taken
> from the OFA doc at
> > http://download-west.oracle.com/docs/html/A97297_01/appg_ofa.htm :
> >
> > 1) Who in their right minds thought it was a good idea to
> name the redos
> > with a ".log" extention? It's asking for trouble, if not
> from a DBA, then
> > from an SA or a script that's used to clean up old log
> files. Why the risk?
> >
> > 2) For similar reasons, I refuse to create the database files under
> > $ORACLE_BASE. How often does a DBA peruse that file tree?
> Daily, for me.
> > Put them on a separate directory off of "/" on Unix, or
> their own drive
> > letter for Winders. Then, anyone wanting to mess with the
> files from the
> > O/S level usually needs to go there on purpose and not by
> accident (unless
> > "root" does an "rm -R *" from "/", in which case there
> ain't a whole lot you
> > can do anyway).
> >
> > 3) Having the administrative directory structure (table
> G-8 on the above
> > link) is impractical at best, and dangerous at worst. If
> you lose one MP
> > (mount point; one set of drives), you lose all instances.
> To prevent this,
> > you'd need to create SEVERAL MPs for each DB, even on a
> small system. This
> > just isn't going to happen. Instead, we make an "admin"
> directory under
> > $ORACLE_BASE, then a "DBNAME" directory for each DB
> underneath that. The
> > appropriate adump, bdump, cdump, udump, pfile, etc.
> directories are then
> > created for each DBNAME. Then, if necessary, each DBNAME
> directory can have
> > their own MP, for recoverability and scalability (I
> wouldn't stretch it to
> > include "performance"!).
> >
> > 4) I think the "/u01", "/u02", etc. MP naming is a pain. They mean
> > nothing. In a disaster recovery, the last thing you want
> is to have someone
> > forget what "/u01" is. This is the 21st century, people!
> We have the power
> > to NAME DIRECTORIES something meaningful!
> >
> > NOFA! :)
> >
> > Rich
> >
> > Rich Jesse System/Database Administrator
> > rjesse_at_qtiworld.com Quad/Tech Inc, Sussex, WI USA
> >
> >
> >
> >> -----Original Message-----
> >> From: Piet de Visser [mailto:piet.de.visser_at_logicacmg.com]
> >> Sent: Tuesday, August 05, 2003 6:39 AM
> >> To: Multiple recipients of list ORACLE-L
> >> Subject: Re: what is BAARF? --- OFA
> >>
> >>
> >> Tim, James, Mogens, Group,
> >>
> >> Another BAARF advocate here...
> >>
> >> However, I recognize Tim's problem when HW vendors:
> >> a) push raid5 or some form of autoraid.
> >> b) push for 8 separate disks of 125G each with only
> >> redo-files on them...
> >>
> >> While the BAARF initiative should continue in its simple,
> >> elegant and forcefull form (hammer the msg home),
> >> I want to place a call to Gary, Tim and others,
> >> to undertake A Revamp of the original OFA paper.
> >>
> >> Determine the new requirements (most of the old ones still stand!)
> >> and from the requirements, enhance the OFA-structure.
> >> It should take into account:
> >> - SAN capabilities (snapshotting and snapshot-logs or caches)
> >> - RAC and Clustered file systems, anticipate on 10G.
> >> - easy of admin: single point of admin per database, not per
> >> instance.
> >> - make provisions for (physical) copies
> >> (acceptance/testing/development)
> >> - standby-db constructions (including for RAC-dbs, and
> >> favour good-old-and-simple sqlplus ;-).
> >> - Weigh the importance of redo-speed against things like
> >> archive-storage and recoverability based on snap-copies.
> >> Separate redo-files only if redo is your bottleneck. Tip:
> Redo-files
> >> are the easiest db-files to move around: just add new groups...
> >>
> >> Any Takers ?
> >> Any ideas for a joint-effort ?
> >>
> >>
> >> Regards,
> >>
> >> PdV
> >>
> >> Oracle DBA.
> >>
> >> DTMWFI, FWIW, JMTC and YMWV (of course it will)
> >>
> >>
> >> PS: Frustration cost me my lunch break.
> >> Me too, Got bitten badly by a hardware vendor recently for _not_
> >> putting aside 35% of my multi-TB disk-capacity exclusively
> for redos.
> >> Salesman dreams to sell an additional nr of disks at 5% utilization
> >> because of the trueism:
> >> "redo files should be on private, physical, devices".
> >> He even knew of OFA, the Oracle-FILE-Architecture :-).
> >> Any advertising, as long as they spell the name right....
>

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: Jesse, Rich
  INET: Rich.Jesse_at_qtiworld.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).