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 [EMAIL PROTECTED] 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 > [EMAIL PROTECTED] Quad/Tech Inc, Sussex, WI USA > > > >> -----Original Message----- >> From: Piet de Visser [mailto:[EMAIL PROTECTED] >> 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: Tim Gorman INET: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] (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).
