Q

Databases on RAID 5 devices, part 2

This is in response to the opinion expressed in the following link: Databases on RAID 5 devices. The expert's answer

is fine as far as it goes, and we are wrestling with the same issue. But the question posed by our resident RAID-5 proponent is: "What then is the alternative"?. If RAID-5 is not good for write-intensive Oracle databases then what is the cost-conscious alternative? That is, in our environment mirroring has been deemed "expensive".

I apologize if I didn't answer your question fully. I hope I answer your question here.

RAID-5 is a cost effective solution, but as it has already been pointed out, it is not very good for write-intensive applications, as databases happen to be. So which alternatives do you have? You could employ RAID-1 or RAID-0+1 which employs mirroring for redundancy. This is a costly solution since you need to double your disk capacity to support an identical mirror. If you are talking about hundreds of gigabytes or especially terabytes, this can get quite expensive, even with today's cheap disk prices. So what else is left?

You could try using what we call JBOD. This stands for Just a Bunch of Disk, or basically disk units with no RAID redudancy on it at all. If you choose this route, then make sure you multiplex your online redo logs and control files. If a disk does go down, any tablespaces on that disk will become unavailable until your recover those datafiles and apply redo. But the rest of the tablespaces will be up and running. You won't lose your entire database in this scenario.

The JBOD option might not appeal to you. And it didn't work with one of our multi-terabyte databases. The more disk units you add to a system, the higher your chances of disk failure. You may wish to still employ RAID to cover yourself. So in that respect, you might want to look at RAID-3. RAID-3 is similar to RAID-5, but a little different. With RAID-3, you get redudancy without mirroring. And you don't get as high of a write penalty found in RAID-5 systems. You still get a write penalty, so RAID-3 is not an ideal solution. But it seems to be a good compromise. And it might just work in your situation. You'll have to test it out to be sure.

Another option is to use a mix of RAID levels. We've done that here as well. We've placed our "read-mostly" datafiles on RAID-5 volumes. And then we've placed our read-intensive datafiles on RAID0+1. For us, this solution worked out well. We didn't have too many read-intensive datafiles. Most of our datafiles were read-mostly. Our bi-monthly dataloads on those RAID-5 tablespaces do take twice as long now, but this only happens once every 2 months so we can live with it.

Now if your situation dictates that you have a highly intensive write environment and you require redundancy, then you are left with coming up with the funds to double your disk and employ RAID-0+1 or RAID-1. Write intensive operations with redudancy will cost.

For More Information

  • What do you think about this answer? E-mail the editors at editor@searchDatabase.com with your feedback.
  • The Best Oracle Web Links: tips, tutorials, scripts, and more.
  • Have an Oracle or SQL tip to offer your fellow DBAs and developers? The best tips submitted will receive a cool prize. Submit your tip today!
  • Ask your technical Oracle and SQL questions -- or help out your peers by answering them -- in our live discussion forums.
  • Ask the Experts yourself: Our SQL, database design, Oracle, SQL Server, DB2, metadata, object-oriented and data warehousing gurus are waiting to answer your toughest questions.

This was first published in March 2002

Dig deeper on Oracle database design and architecture

Pro+

Features

Enjoy the benefits of Pro+ membership, learn more and join.

Have a question for an expert?

Please add a title for your question

Get answers from a TechTarget expert on whatever's puzzling you.

You will be able to add details on the next page.

0 comments

Oldest 

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

SearchDataManagement

SearchBusinessAnalytics

SearchSAP

SearchSQLServer

TheServerSide

SearchDataCenter

SearchContentManagement

SearchFinancialApplications

Close