Raiding hard-drives

Bokers

If it's for backup then take a look at RAID 5

Johnmcl7

I agree we need more information on the setup to be able to give advice. My immediate question would be what backups is he planning to take? People frequently mistake a RAID solution as backup system but it isn't, it is very useful and does mean systems can continue when a drive fails but it doesn't protect a system in the way a separate back up can. The problem is if the data is corrupted for some reason it will be corrupted on both drives and the reason for one drive being lost can happen to both at the same time if there is a problem with power that kills both the drives or the they are stolen.

By copying the data nightly onto an external drive of some sort which is locked away somewhere else during the day it gives an extra level of protection on top of using a RAID array to ensure the system can recover from data corruption or if the array is lost entirely for some reason.

John

RobTang

Bokers wrote: »

If it's for backup then take a look at RAID 5

some DBAs ive talked to dont like raid5, they prefer raid10, party for performance partly because it slightly more redundant.

Actually raid5 has fallen out of favor because of its not that suitable for large drives, because during the rebuild the existing drives gets hammerd with no avaliable backup, these days raid6 at a min.

Mr_Toad

Are we talking about a proper database, something like Oracle?

This is probably going to be way over the top but here goes......

As an Oracle DBA the preferred choice is a combination of RAID 0 and RAID 1 also called RAID 10 Oracle call this SAME - Strip and Mirror Everything.

RobTang is right, we don't like RAID 5 there's a performance hit of about 20% on write speed due to several write operations to update the parity data. This is variable depending on the number of members in the array.

To do it properly you also need lots of disks, doing it with 4 isn't going to give you much advantage.

For performance you want the ORACLE_HOME on one disk, SYSTEM Tablespace and control files on another and separate disks for each DATA, INDEX and TEMP Tablespaces, Archive logs and Redo logs also need separate disks. Isolating the log files from the data is important, so that's 9 disks striped plus another 9 for the mirrors. This can be just the start, you could need more spindles depending on the size of the database and the number of users/transactions.

I have several books on this subject that make War and Peace look like pamphlets!

If it's a Microsoft SQL Server DB then I've never worked with that but I suspect the same basic rules apply.

Or are we talking about an Access DB with a couple of users? In which case who knows :0)

rmg1

To answer answer these in some semblance of order (and apologies for anything I miss).

Uploads - approximately 0.5GB day - needs to be as fast as possible.
RAID controller - there should be a dedicated RAID card in place (anything else and I'm not touching it with a bargepole!!).
Reads - again need to be as fast as possible.
Database - it's going to be SQL
Backups - I can probably convince him to get some more drives for backup purposes which takes care of that bit and do the backups overnight.

Think I've covered all the questions (feel free to point and laugh if I've missed any)..

Mr_Toad

Being familiar only with Oracle I'm just going to sit back and watch this one.

I hope you get it sorted to everyone's satisfaction.

paddyrg

http://technet.microsoft.com/en-us/library/cc966534.aspx
http://www.dbforums.com/microsoft-sql-server/1640912-recommended-disk-architecture-raid-etc-sql-server.html
http://www.tek-tips.com/faqs.cfm?fid=5747
http://dinesql.blogspot.co.uk/2010/05/raid-for-sql-server-advantages-and.html

The question is more than just RAIDing - although it won't be the biggest speed-block. I would personally worry less about RAIDing than separating the TLog and DB files, and depending on the skill of the developer writing the queries maybe sling tempdb on a separate spindle... but that depends on if they're cursor-intensive or setwise. Maybe also a staging spindle for the data files on the way in.

Basically the RAIDing is a part of the whole system architecture, and there is still a massive chunk of 'it depends' depending on some quite specific stuff. I would say if this is intended to be a desktop/multi-use box then look at making it a real server. If this is going to be a server in a rack being a dedicated DB system, can you look at a SAN solution instead which may be more economical and give you better scaling.

BTW a half-gig a day will make for a fast growing DB - make sure you set the database up correctly (not to autogrow which will be messy) and you will need to really provision for re-indexing, depending on how you are importing the data - it may be fastest to BCP then reindex manually/rebuild the stats than use the serialised tools. Also, is historical data actually relevant? Or are you just querying that day's data? If the latter, have a policy to truncate the tables and t-log as a part of the import (and forget having any mirrors - pointless), or if the former it is important to know indexing time will grow exponentially as data does. The architecture of your data system will make the hugest difference to speed and performance - RAID will be the least relevant of these factors.

demystified

Can't see the point honestly, SSD's are coming down in prices rapidly and they'll beat any mechanical hard drives in RAID 0 on speed, which is not a safe place to permanently store data in any case.

I use an SSD for the OS drive and mechanical hard drive 2.5TB for storage/backup myself, if I did have a 2nd backup drive I'd mirror it so theres a identical backup on both drives, theres no way on earth I'd stripe it.

Mr_Toad

I think SSDs have a way to go yet in terms of size, data not physical, before they make large inroads into the commercial Database arena.

It is starting to happen though. Oracle Sun SSD come in 100GB and there are companies like Violin Memory offering Flash devices that are 50x faster than SSDs

People talk about RAID and backup in the same breath, RAID isn't a backup solution. Striping offers speed while mirroring offers redundancy not a backup.

If you lose a spindle your system doesn't go down and you can still access the data while the engineers pull and replace the faulty drive with a new one which is then re-silvered.

rmg1

Thanks for the info guys, we've got a lot to think about before we go any further with this.