| 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: EMC - Hitachi
Ganapathi,
Yes, the number of spindles does matter even with a 2Gb cache. Actually a 2Gb cache may not that much depending on the volume of transactions in your environment. We have seen 16Gb caches in very heavy transactional environments getting saturated. So a cache can only take you so far. So for example, don't pick RAID5 for write-intensive applications just because you have a 2Gb cache. The cache can vanish in a hurry and your system may experience significant I/O waits caused by the parity calculations.
For the sake of our discussion, a spindle is a physical disk (just so that we are on the same page). Obviously, when you create any logical volumes and implement some level of RAID on it, we will treate the entire volume as 1 spindle, as it will be uniquely identified as i device (unless you start slicing and dicing at the logical volume level and then mount multiple file systems on the same set of drives...not a good way to design your I/O sub-system).
You also need to look at your database layout from a size perspective, database partitioning requirements, parallelism requirements and availability requirements (do you need partial availability of data, if you did suffer from multiple media failures).
Don't buy the story from anyone who says the following - 'create 1 huge volume, put everything on it, and we will take care it' (the concept of thin wide striping). Magic will not happen with disks regardless of the vendor and when your batch jobs kick in and perform range scans on your huge indexes, your system might experience significant I/O waits, if your DATA and INDX tablespaces are on the same set of physical drives. We have seen this happen with uncanny accuracy at many sites and doing something simple such as moving the INDX datafiles to a separate volume does wonders.
Use the usual DBA101 placement rules - separate DATA and INDX, separate redo logs etc. You may want to download a paper I presented on 'Implementing RAID on Oracle Systems' at OOW 2000. This has more detail than what I can write here. Understand what each level of RAID offers and then choose the right level based on your applications's I/O patterns and the number of users. As you can see, the answers to your question are multi-faceted and complex. Enjoy the ride! May the force be with you!
Cheers,
Gaja
Author - Oracle Tuning 101 by Osborne McGraw-Hill "Opinions and views expressed are my own and not of Quest"
 |
 |