Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

So I'm building out a SQL Server 2008 R2 x64...Will be running a single user database of about 2GB, maybe 80/20 read/write, and about 100 users.

Base hardware would be DL380, 12GB RAM, and dual 6-core Xeons. Now I'm hung up on the disk configuration...

Option 1
RAID 1 60GB SSD (OS, SQL Files, TLog, TempDB)
RAID 1 120GB SSD (DB files)

or

Option 2
RAID 1 146GB 15K (OS, SQL Files)
RAID 1 146GB 15K (Tlogs, TempDB)
RAID 10 4x148GB 15K (DB files)

Some perfmon numbers from my current production server:
Memory Avail MBytes - 813 (server has 4GB of Memory)
Page life expectancy - 496854avg
Batch request/sec - 7.5avg 97.595max
SQL Compilations - 3.422avg 27.599max
SQL Re-Compilations - 0.002 0.200max

Business priority is more reliability then performance.

Which of the above disk configurations would you rather have?? Cost diff is about +$2700 for the SSDs (also need a second, mirror server). Would SSDs even make a difference for such a small database?? I could imagine with 12GB I would have enough physical memory for the entire db, right???

Appreciate any feedback...Thanks!

share|improve this question

3 Answers 3

I've read about SSDs having high failure rates; so if reliability is the priority, I'd go with the 15k SAS drives.

Either way, with RAID you have disk fault tolerence, but you'd probably have best luck with 15k SAS. We've run loads of dell servers with 15k SAS drives, and they have been rock solid.

share|improve this answer
    
I agree. SSDs still have a little way to go with reliability. Go with the fastest drives you can afford for your SQL data and log drives. Disk I/O is one of the biggest performance killers of a database server especially if TempDB is used a lot. RAID 10 is a good choice for your SQL drives. –  Rob May 27 '11 at 18:09
    
If performance was critical, RAID and SSDs can give you the extra performance you might need; but if thats not the primary goal, spinning drives are the way to go. –  Nate May 27 '11 at 18:12
    
Thanks for that article on failure rates...but I got the feeling Jeff was mostly referring to consumer class SSDs as opposed to "Enterprise Class" SSDs. Actually, is there even a difference? perhaps MLC vs SLC?? –  Chop May 27 '11 at 23:41

With SSD there is a higher chance of disk blocks zapping. If you have an OLTP DB, this is not a good idea, even though you get much much faster seek times for your reads/writes. You may also have to run much more frequent DBCC checks on the DB to rule out corrupt sections on the SSD. For an OLAP system, SSD becomes a bit more acceptable, but you still have the same pros and cons.

share|improve this answer

If the priority is reliability, go with option 2 and stay away from SSD.

With so much memory and such a small database, storage performance for reads won't matter much anyway.

After some query activity on the database, everything will be in RAM. SQL shouldn't touch the disk again except to update via the lazy writer.

I would keep that one pair for log only and put tempdb data files on the RAID volume, with you other data files. It seema unlikely that you would be doing physical IO to your data files and tempdb at the same time. Putting on the logs on that pair will make it easier for the write caches for that pair to keep up and minimize disk head movement,which is the real enemy. You want log writes to be fast because they are synchronus with respect to your DML. Data writes can be slower because they are cached by SQL Server and are asynchronous.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.