does anyoen disagree? Didnt this get started with the 'DBA Handbook' or was it a 
different text? 

> 
> From: "Mercadante, Thomas F" <[EMAIL PROTECTED]>
> Date: 2003/07/15 Tue AM 11:10:05 EDT
> To: Multiple recipients of list ORACLE-L <[EMAIL PROTECTED]>
> Subject: RE: should you seperate indexes from tables in seperate datafiles
> 
> R,
> 
> Some of it depends on the disk storage.  I have always followed the
> time-proven method of organizing disks and placing indexes away from the
> tables they belong to.
> 
> Our warehouse is using EMC external disk.  What the warehouse architect did
> was to stripe the EMC disks in such a way that all mount points (Sun system)
> are spread across all the EMC disks.  What this does is to spread all files
> in the database across all the EMC drives.  And with 4 Gig of EMC cache
> available, it further disproves the theory that separing indexes from data
> are required.  The end result, in my case, is almost like one big RAM disk -
> where all disk IO is spread across all disk.
> 
> If you do not have this arrangement, then I would still try and keep indexes
> and data away from each other.  But let's face it, we *never* have enough
> disk mount points, so we end up merging things together somewhat anyway.
> 
> hope this helps.
> 
> Tom Mercadante
> Oracle Certified Professional
> 
> 
> -----Original Message-----
> Sent: Tuesday, July 15, 2003 10:49 AM
> To: Multiple recipients of list ORACLE-L
> 
> 
> There has been alot of literature stating that you will recieve performance
> improvements by seperating indexes and tables across multiple I/O points.
> 
> Ie... you have a tables tablespace and an index tablespace. If you put them
> on seperate hard drives, you will have less I/O contention.
> 
> Now Im seeing some articles stating that this is not true. That oracle
> actually accesses indexes and tables serially. Now it might be useful
> seperate indexes from tables for maintenance purposes but this wont lower
> I/O contention.
> 
> Can anyone chime in on this? Curious to see where the evidence is leading? 
> 
> -- 
> Please see the official ORACLE-L FAQ: http://www.orafaq.net
> -- 
> Author: <[EMAIL PROTECTED]
>   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: Mercadante, Thomas F
>   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: <[EMAIL PROTECTED]
  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