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: Thomas Day
  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).

Reply via email to