raid

RAID

RAID is an acronym for Redundant Arrays of Inexpensive Disks. These provide a mechanism for load balancing and securing your data across multiple disks. In this article I'll give a brief explanation of the most commonly used RAID levels and how they should be used with Oracle.

RAID Levels

Here are a few of the most commonly used RAID levels

 

RAID Level	Description
None	Any RAID operation involves a certain management overhead so if your requirement is for optimum write speed and no data protection you may choose to avoid RAID.
0	This RAID level provides automatic block level striping of data across multiple disks to balance the load across the disk array. It provides no protection from data loss!
1	This RAID level is also known as disk mirroring. The RAID controller keeps a complete copy of each disk on at least one other disk. In the event of a disk failure the RAID controller switches to one of the mirrors to prevent system failure. Double or tripple mirroring can be used to provide increased levels of security.
0+1	As the name suggests this is a combination of RAID 0 and RAID 1, providing the benefits of block level striping across the array and the security of disk mirroring. In some ways this is the ideal RAID configuration in terms of performance and availability, but it can be expensive as it requires at least twice the amount of disk space.
5	This RAID level stripes data and parity information across 3 or more disks. The parity information, which is always stored on a separate disk to its corresponding data, allows the contents of lost blocks to be derived. The overhead associated with this RAID level make it slower than the previous methods, especially when a disk failure occurs, but it requires far fewer disks so it is very cost effective. In the past people have avoided RAID 5 for database applications but improvements in disk speed and controller performance mean that it is a viable solution for datafiles that do not require heavy amounts of I/O.

Oracle RAID Usage

So we know what the different RAID levels do but which level should be use for Oracle? The answers are not carved in stone but here are some suggestions:

File Type	Preferred RAID Level	Comments
Control Files	No RAID, RAID 0 or RAID 0+1	Control files are updated constantly so the quicker they can be accessed the better. Multiple control files should always be used whether you use RAID or not. When using no RAID or RAID 0 it is up to you to make sure that at least one copy of the control file is always available.
Online Redo Logs	No RAID, RAID 0 or RAID 0+1	Similar access requirements to control files. Once again, the redo logs should always be multiplexed whether you use RAID or not.
Temporary Datafiles	No RAID or RAID 0	The main requirement here is rapid access, not reliability. If the datafile is lost it can simply be recreated as there is no data to restore.
Archived Redo Logs	No RAID, RAID 0 or RAID 0+1	Multiplex these if using no RAID or RAID 0. If you're using RAID 0+1 let the hardware multiplex them for you.
Rollback/Undo Datafiles	RAID 0+1	These files require constant I/O and must be protected. They cannot be mutliplexed by Oracle so let the hardware do it for you.
Datafiles	RAID 0+1 or RAID 5	Most I/O operations to datafiles are buffered, with the physical writes happening in the background. As a result RAID 5 can be used to reduce costs without a significant impact on performance. Even so, datafiles with heavy I/O requirements should use RAID 0+1 where possible.

Conclusion

As most Oracle DBAs know, rules of thumb can be misleading but here goes:

• If you can afford it use RAID 0+1 for all your Oracle files and you shouldn't run into too many problems.
• To reduce costs move datafiles with lower access rates to RAID 5.
• To reduce costs further move the other datafiles to RAID 5.
• To reduce costs further experiment with moving archived redo logs and rollback/undo tablespaces to RAID 5. Pick the combinations that work best for your system.
• If cost dictates it, move all your Oracle files on to RAID 5.

Hope this helps. Regards Tim...