|
Personally, I hate using RAID 5 for database systems. And many, many
top industry experts agree with me. Database systems are
write-intensive creatures. Just to keep an Oracle database up and
running and fulfilling requests, you need to have online redo logs,
undo space, temporary sort space, not to mention write intensive
operations (like INSERT, UPDATE, and DELETE statements) that hit your
database's datafiles. So a database can generate lots of write
requests. RAID 5 includes a write penalty caused by the method in which
it calculates and stores parity bit information to be used in the event
of a failure. So knowing that your database is most likely write
intensive, why would you choose a RAID level that includes a write
penalty? RAID 5 on write intensive datafiles will introduce a
performance bottleneck. For that reason, I stay away from RAID 5 for
databases unless I have very specific reasons to choose otherwise.
RAID 5 is very good for read operations though since the file is
striped across multiple disk volumes. If your database is READ MOSTLY,
then you may consider RAID 5, but that is rarely the case. RAID 0+1
does not have the write penalty like RAID 5 does. And RAID 0+1 also
stripes the data so the read performance is as good as RAID 5. The only
downside to RAID 0+1 is that you waste more physical disk space to set
up the redundancy. But if I had my vote, it would go to RAID 0+1 every
time over RAID 5.
|