what raid config for Database server

>or raid 10 on 6 disc no hotpare (is this possible)
yes

what about
+ 2 disks for a RAID 1 ( mirror ) -> OS + log files
+ 4 disks RAID 5 -> data files

That sounds reasonabl, esp. if you don't have a very large volume of modifications (inserts / updates / deletes).


>> And, what kind of block size should I choose for the array / partitions? <<
64K


Also, it's very important to make sure the disks are properly aligned so that you don't do extra I/O.  Do a Google search for "sql server disk partition alignment" for more info.

Assuming you want a dedicated database server (file system files are placed elsewhere), which means just the o/s itself; MS SQL itself and all required structures; and the SQL Devices (which contain the databases, and the contents of the databases):

1  Definitely not RAID5 for databases
2  (the notion of having hot spares AND mirroring needs to be examined)
Raid 10 across 6 disks, with no hot spare
3  You can also look at Raid 01 with a spare

Blocksize.  For a db srever, keep it small but not too small.  16k.

Cheers

Hi guys thanks for the responses.... though as I feard 3 people 3 different opinions...

1) Can you eleborate your anwsers, and explain why you advise the setups?
2) Is there some kind of 'mother of all configs guide' online?

http://www.microsoft.com/technet/prodtechnol/sql/2005/physdbstor.mspx - it's for 2005 but I think applies to 2000 as well.

>> and given that sometimes the server will read more than one 2k page sequentially, we can safely go up a notch from the minimum of 8k to 16k <<

SQL Server reads/writes to disk in 64K blocks. Thus there is no reason to use a smaller blocksize; an 8/16k physical block just causes unnecessary i/o "chaining".

Yup, and even if you use a bigger block size (128K) and accidentally read something you don't need the disk head was there anyway.

Dell have a great graph showing a 1% performance gain by tuning MS Exchange down to its "correct" block size from having the stripe size too big whereas it shows about 20% performance loss by having it too small. SQL and any other DB is no different, suck as much data off the disk when the head is in the right place because it take a long time to seek to another track.

Tuning it through diskpar(t) ain't much use either since the logical disk mapping doesn't relate to the physical. I can give you 1% improvement for a day's work tuning it but for my daily charge you could have bought another disk.

But the initial sector aligment using diskpar(t) is *vital*.  You'll lose up to 40% in performance otherwise.

Nope. It's vital when trying to explain how to tune disk subsystems but in the real world any physical disk might have to do a long seek to get to a spared-out sector. Diskpar is wonderful if you have perfect disks without any errors on them  but in the real world oxide on platters isn't perfect so there are unexpected random seeks when the disk goes slow to get past a dodgy bit of oxide.

The comment box is less than a character high again so I might hace made lots of typos, EE is going down hill as far as the UI is concerned.

RAID-10 for everything is definitely better if you can afford it.  Most people can't, just because of the economics of doubling the drive space for everything :-) .

Making sure the sectors are properly assigned is a well-known issue for SQL Server.  It has nothing to do with the mix of work load on the box after it is up and running.  That's immaterial, since you're having to read extra sectors regardless.

Wow... I seem to have started quite the debate here :)

RAID 10 it will probably be then. If all (or most) of you agree... I'd go RAID 1+0 on 6 disks.

The block size I'll let you argue about for a while longer and see what surfaces.

Points will be awarded all arround :)

So would you guys agree that if I run a RAID 1+0 on  6 disks with a 64k strip size / block size, that I get close to optimal performance?

Look, trying to get a few guys who have had lots of experience each is not the question.  Each of us, due to our hard-earned experience, has reached our conclusions/positions, and we are probably quite attached to them.  Best advice for you is, think about the different responses, and make a (now informed) decision.  When you have issues 3 years from now, you will know from experience, which direction was the most true.  But that cannot be reached right now; not unless we obtain a mass of info from you; and certainly not by debate.  Just choose one, the responsibility is yours.  "take what you like and leave the rest."

Notice that I do not participate further than providing the requested information.  I am not "agreeing" to anything other than my post.

There is no such thing as the mother of all configurations; even if there were, it would (by definition) be generic.  The whole idea and goal of configuration is the specific, therefore non-generic, act of setting hardware parms for your specific collection of bits and pieces, and importantly, for the specific use.  Therefore by definition, the mother of all configs, isn't.

BTW, I am not disagreeing that head movement is the only moving part in the whole chain relating to performance and therefore the slowest.  However, there is no need to suck up the whole 64k (wait for it) unless you have somewhere to put it.  Which means a rather large cache, for stuff beyond what you need, just because you picked it up, just because you were nearby.  Therefore, if you are not caching the 64k, then do not bother reading it, read 16k, and get on with the next head movement.  Read speed is not the issue, cache space is.

For the life of me, I do not understand why anyone would believe MS, given their consistent and abysmal record recredibility.  Forced to buy a new box, to run the new o/s ... and the box needs a new o/s ... which needs a new box.  People actually accept this insanity from the gods of commerce.  Anyway, do not listen to them (unless you are willing to buy a new box ...)