There is a great debate about the benefits of segregating index and table data into separate tablespaces and/or separate physical disks.  There are three areas to consider when looking at index and table segregation, and separating indexes and table data is considered an Oracle best practice:

• Run-time performance

• Reporting/monitoring

• Manageability

From a performance perspective, some experts note that Oracle will rarely read and index block and a data block at the same time.  However, having data and index data on the same physical disk spindle may contribute to disk enqueue contention:

In some cases of very large databases, index and table data are further segregated into separate data buffers, each with a different size:

Segregating large indexes and tables into separate tablespaces makes large objects easier to manage, and object segregation allows for easier reporting too. There are several compelling reasons for segregating your large tables into separate tablespaces.

The most important benefit from segregation is improved manageability of the table. If a large, active table resides in its own separate tablespace, you can control the I/O by moving the tablespace to different disks. The other reason for table segregation is improved space usage.  Having too many tables residing in a single tablespace can make reorganization more risky.

How to separate tables and indexes

There are several layers of logical and physical segregation for tables and indexes, each with it's own features, advantages and disadvantages:
 

• Move tables and indexes onto separate datafiles, on different disks.
   

• Move tables and indexes into their own datafiles, but put them on the same physical disk.
   

• Partition the indexes and tables, mapping the tables onto separate tablespaces based on a key or hash value. The tablespaces, in-turn, are mapped to datafiles that reside on independent disk spindles).  

There are many compelling reasons to separate Oracle tables and indexes onto separate disks:

• Easier DBA organization - By separating tables and indexes onto separate tablespaces, it becomes easier to spot "hot" objects and manager recovery. For example, if you place all of your indexes on a separate disk, you don't have to worry if the disk of backup becomes corrupt because you can rebuild the indexes to restore the device.
   

• Better reporting - By segregating related tables onto separate data files, it's easier to track I/O at the data file and tablespace level. In a large multi-disk database, the smart DBA will map all giant tables to their own set of disks, so that the OS level disk I/O reports point to the activity of a specific table or index.
   

• I/O balancing - Some say that it's a myth that segregating tables and indexes onto separate disks doe not help because Oracle never reads the index and table at the same instance. For a single task, yes, but in a real-world database with hundreds of concurrent tasks, you may see serious disk enqueues, as the disk read-write heads slam around, trying to serve-up data blocks from distant cylinders.