If we use RAID 0+1, wouldnt striping be enough instead of seperating indexes and data in two different tablespaces??? They will be stored in different disks anyway no?
Printable View
If we use RAID 0+1, wouldnt striping be enough instead of seperating indexes and data in two different tablespaces??? They will be stored in different disks anyway no?
What is the question here?
The datafiles will be spread onto multiple disks (striped) yes, however this does not stop fragentation at the tablespace level and does not conform to OFA.
So although you probably won't see a performance increase by seperating them out it is a standard.
Tablespace Fragmentation depends on OS fragmentation so it´s not really an issue here, I think i wouldnt care about database fragmentation anymore for those tables which wont be scanned fully for a query.
Seperating indexes and data in Raid 0+1... I dont see much point in perfomance issue except that it´s probably easier to administer otherwise we could just have everything in one tablespace (everything!) :D
Placing tables and indexes in seperate tablespaces will reduce I/O contention and thus result in better performance regardless of the RAID level. Index and Data tablespaces typically reside on different mount points. These mount points are groups of physical disks. Yes, if you place a datafile on a 0+1 device, it will be stiped across x number of disks. However, if you put a datafile for the data tablespace on one set of 0+1 disk and your index tablespace datafile on another set of 0+1 disk, you have two sets of disks spinning during a query instead of just one. In an ideal world, these to filesystems would be controlled by two different disk controllers.
0+1 is just a disk technology. As a DBA you must always think of disk resource as a single disk to eliminate I/O contention. In this situation you have to ask yourself, "Would I put my data and indexes on this disk if it were a single 9G 5400RPM drive?"