Oh, plenty of times. Just never heard it referred to as "OFA".
on 9/29/03 7:04 AM, Thomas Day at [EMAIL PROTECTED] wrote: > > My struggle is not with the directory layout OFA. > > It is with the "mythical" OFA that every DBA that I have talked to knows > all about. Where ORACLE says that if you are a good and competent DBA you > will separate your table data and your index data into two separate > tablespaces so that one disk head can be reading index entries while > another disk head is reading the table data. You've never run into that? > > > > > Tim Gorman <tim > @sagelogix.com> To: Multiple recipients of > list ORACLE-L <[EMAIL PROTECTED]> > Sent by: cc: > ml-errors Subject: Re: BAARF > > > 09/28/2003 09:44 > PM > Please respond > to ORACLE-L > > > > > > > Thomas, > > Please pardon me, but you are off-target in your criticisms of OFA. > > It has never advocated separating tables from indexes for performance > purposes. Ironically, your email starts to touch on the real reason for > separating them (i.e. different types of I/O, different recovery > requirements, etc). Tables and indexes do belong in different tablespaces, > but not for reasons of performance. > > Cary first designed and implemented OFA in the early 90s and formalized it > into a paper in 1995. Quite frankly, it is a brilliant set of rules of how > Oracle-based systems should be structured, and a breath of fresh air from > the simplistic way that Oracle installers laid things out at the time. It > took several years for Oracle Development to see the light and become > OFA-compliant, and not a moment too soon either. Just imagine if > everything > were still installed into a single directory tree under ORACLE_HOME? All > of things you mention here have nothing to do with OFA. > > Please read the paper. > > Hope this helps... > > -Tim > > P.S. By the way, multiple block sizes are not intended for performance > optimization; they merely enable transportable tablespaces between > databases with different block sizes. > > > on 9/25/03 11:04 AM, Thomas Day at [EMAIL PROTECTED] wrote: > >> >> I would love to have a definitive site that I could send all RAID-F >> advocates to where it would be laid out clearly, unambiguously, and >> definitively what storage types should be used for what purpose. >> >> Redo logs on RAID 0 with Oracle duplexing (y/n)? >> Rollback (or undo) ditto? >> Write intensive tablespaces on RAID 1+0 (or should that be 0+1)? >> Read intensive tablespaces on RAID ? (I guess 5 is OK since it's cheaper >> than 1+0 and you won't have the write penalty) >> >> 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? >> >> We have killed the "everything in one extent" myth haven't we? > Everybody's >> comfortable with tables that have 100's of extents? >> >> And while we're at it, could we include the Oracle 9 multiple blocksizes >> and how to use them. The best that I've seen is indexes in big blocks, >> tables in small blocks --- uh, oh, time to separate tables and indexes. >> >> Maybe we will never get rid of the OFA myth. >> >> Just venting. >> >> Tired of arguing in front of management with Oracle certified DBAs that >> RAID 5 is not good, OFA is unnecessary, and uniform extents is the only > way >> to go. Looking for a big stick to catch their attention with. >> > > -- > 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). > > > > -- 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).
