Feedback On Proposed Drive/RAID Configuration For New SQL 2008R2 System

  • Forgot to include the VMware vSphere pricing page link.

  • [Comment below; attempted to edit, instead it was re-posted with edits, so I removed the original comment.]

    SQL DBA,SQL Server MVP(07, 08, 09) A socialist is someone who will give you the shirt off *someone else's* back.

  • Tempdb drives are much too small. SQL uses tempdb a lot, and you can't afford to run out of tempdb space.

    I would not dismiss RAID5 for the db data so quickly. Reads are faster on RAID5, although writes are much slower of course. Proper selection here requires more investigation.

    I agree that tempdb data should not be on RAID5, since it is a higher % of write vs read.

    SQL DBA,SQL Server MVP(07, 08, 09) A socialist is someone who will give you the shirt off *someone else's* back.

  • ScottPletcher (7/27/2012)


    Tempdb drives are much too small. SQL uses tempdb a lot, and you can't afford to run out of tempdb space.

    I would not dismiss RAID5 for the db data so quickly. Reads are faster on RAID5, although writes are much slower of course. Proper selection here requires more investigation.

    I agree that tempdb data should not be on RAID5, since it is a higher % of write vs read.

    I don't have the links anymore, but I did quite a bit of research a few years ago and that research pushed me away from RAID 5 to RAID 10 for my database servers.

    Best thing I can suggest here is do your research, then make your decision. If I had to support this type of decision now, I'd be back doing my research as I know that just saying this is how it should be you need to know for sure.

    Also helps if you can stress test several configurations prior to actual deployment.

  • BAARF - http://www.baarf.com/

  • Steve Jones - SSC Editor (7/26/2012)


    SpringTownDBA (7/26/2012)


    Ok, I understand what you're describing.

    If the VM host is ONLY going to host 1 VM EVER, then what is the value added by vmware? It's not free, and does introduce some (slight) overhead so it needs to be justified to be thrown into the mix. What is their justification?

    Of course, if I was a shady sysadmin, I could say it would be dedicated to sql server, then later sneak some additional VM's onto it. That pesky DBA would never notice his server slowing down one day, and if he did complain, I could move the extra VM's off....

    hardware abstraction. Zero issues in moving hardware from the windows side. Ease of migration to new hardware.

    There are some nice benefits on 1:1 host:vm planning. Especially if you install this as a single node cluster (and you should think about it).

    Steve

    Possible dumb question but when you recomedn isntalling as a single node cluster are yo talking about installing SQL Server this way or VM Ware? IO know littel about VMWare so this may sound like a dumb/illogcial question to a VMWare savvy user.

    thanks

    Kindest Regards,

    Just say No to Facebook!
  • Sorry, perhaps I was not clear.

    Install SQL Server as a single node cluster. This allows you to easily add another node to it later, and there is no downside. If you are using a VM, then there is no hardware mismatch, and you could easily bring up another VM with a second node later for HA/DR purposes.

  • Do you really consider having all databases set to SIMPLE RECOVERY MODE?

    I ask because you stated only 200GB Logfile space for 1000GB of dataspace.

    Hope you never get index problems and have to rebuild or reorganize them.

    I also would never put Datafiles on a D-drive because in all systems this defaults to CD or DVD if somethings go wrong and your data can become unobtainable.

Viewing 8 posts - 16 through 22 (of 22 total)

You must be logged in to reply to this topic. Login to reply