| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Mailing Lists -> Oracle-L -> Re: BAARF
I agree, though I'm not sure if it is because indexes are more susceptible
to corruption. My guess is that given 50-50 odds, sometimes you get lucky.
Mixing tables and indexes together gives you 0% odds of losing data... :-)
Well, to add another couple of pennies worth...
In my very first gig as a DBA ten years ago, we were faced with a 7.0.15 database that was doubling in size every few months. Management had already decided to scrap the system and migrate to another, so they refused to buy more storage even though it was production. Long story short, we were forced to unmirror the RAID-1 volumes underneath the index tablespaces and use the freed-up plexes to create new volumes for table tablespaces. Indexes are ancillary structures and ultimately expendable; tables are *data*...
on 9/29/03 7:09 AM, Hitchman, Peter at peter.hitchman_at_derwent.co.uk wrote:
> Hi,
> To add my two pennies worth. By design I create physical database lqyouts
> that seperate indexes and tables by tablespace for ease of management,
> unless the database is real small. My experience over the years with Oracle,
> has been the object corruptions in the database have occurred more frequenty
> with indexes than tables, and when it happens its good just to be able to
> scrap the index tablespaces datafiles and start again.
>
> Regards
>
> Pete
>
> -----Original Message-----
> Sent: 29 September 2003 02:45
> To: Multiple recipients of list 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 tday6_at_csc.com 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?
>> 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
-- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Tim Gorman INET: tim_at_sagelogix.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).Received on Mon Sep 29 2003 - 23:09:43 CDT
 |
 |