RE: what is BAARF? --- OFA

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).