Datafiles in swapping mode - for performance

Question

Hi there,
One of the Senior DBAs told me that it is better to keep the datafiles in swapping mode, which means..
Suppose we need to create 4 Tablespaces, 2 for data files and 2 for index files and we have two drives called E, F. In this case he said, the performance will be increased if we prepare
E drive
Datafile_Tablespace_A (datafile TS no. 1)
Index_Tablespace_D (index TS for datafile no.2)
F drive
Index_Tablespace_B (index TS for datafile no.1)
Datafile_Tablespace_C (datafile TS no. 2)
According to him, Oracle works better in swapping mode, is it true? I was under the impression that index and datafile tablespaces should be built on separate drives.
Even though my quetions is in general, for reference - The OS we are using is windows 2003 server and parition is Raid-5 and the Oralce 10.2.0.1 version.
If anybody can clarify, I would be obliged.
Thanks

Answer 1

I'm going to default to one of Billy's responses:
{message:id=4060608}
>
Irrelevant as that does not change any of the storage fundamentals in Oracle. The database does not know or care what you use as storage system.. why should it? It is the kernel and disk/file system drivers job to deal with the actual storage hardware. From a database perspective, it wants the ability to read() and write() - in other words, use the standard I/O interface provided by the kernel.
I/O performance must not be factor. If it is, then you storage layer is incorrectly designed and implemented. Striping (RAID 0) for example must be dealt with at the storage layer and not at the application layer. Tablespaces and datafiles in Oracle makes extremely poor tools to implement striping of any sort. It does not make sense to attempt I/O balancing such as striping at tablespace and datafile level in Oracle.
So why then use separate tablespaces? You may need different tablespaces to implement different block sizes for performance.. but this is an exception to the rule. And you do not address actual storage performance here, but more how Oracle should manage the smallest unit of data in the tablespace.
So besides this exception, what other reasons? Could be you want to physically separate one logical data base (Oracle schema) from another. Could be that you want to implement transportable tablespaces.
All these requirements are quite explicit in that more than one tablespace is needed. If there is no such requirement, why then consider using multiple tablespaces? It only increases the complexity of space management.
Consider using different tablespaces for indexes and table data. In a year's time, you may find that the index tablespace has been oversized and the data tablespace undersized. You now have too much space on the one hand, too little on the other, and no easy way to "move" the freespace to where it is needed.
It is far easier to deal with a single tablespace - as it allows far more flexibility in how you use that for data and index objects, then attempting some kind of split.
So I will look for a sound and unambiguous technical requirement that very clearly says "multiple tablespaces needed". If not, I will not beat myself over the head trying to find reasons for implementing multiple tablespaces.>
There are also many other threads on this forum about separating data and indexes, try and search for them.