we are in process of setting up our SQL server which is clustered across 2 HP DL380p servers using a HP P2000 for the shared storage with 2 raid 10 (8 disks) arrays and raid 1 mirror (2 disks). We have created 3 LUNS (LUN10, 20, 30) and have created 5 separate VHDx files. 1. OS/SQL (LUN10) 2. MDF (LUN10) 3. LDF (LUN 20) 4. TempDB (LUN30)

My only concern is putting the OS and SQL install and Database files on the same LUN? Is this something that is not recommended or does it really not make a difference? They are separate VHDx files [OS / SQL Install VHD] and [MDF files VHD] but still reside on the same LUN with the same spindles. Do you recommend moving the OS to its own completely independent set of disks? I am guessing there will hardly be any activity on the (OS and SQL binary install VHDx) to justify its need for its own set of spindles? Can they share the same spindles as the MDF files?


  • Is this fibre-channel, iSCSI or SAS-attached storage?
    – ewwhite
    Oct 22 '14 at 12:24
  • 1
    Wait... are you working on the same installation you started in March? And there were additional answers to your query in July. Hmm...
    – ewwhite
    Oct 22 '14 at 12:35
  • Yes, its the same installation, its an ERP installation which takes months and since Dynamics AX R3 was released so many new concerns and business decisions were made, thus giving me a little more time to work on the setup. The questions in March and July were with regards to different questions which have been a fantastic help. Thanks.
    – dqnet
    Oct 23 '14 at 5:51

OS disk-usage on SQL Servers are if anything minimal during normal operation. They only generate load during updates.

What's more concerning is that you're placing your log and datafiles on the same spindles. This is quite the contrast to the recommended setup where you always try to separate the log I/O from the database I/O.. this also applies to tempDB in certain situations.

I would probably opt for something like this:

  • 2 disks in RAID1 for the OS
  • 2 disks in RAID1 for logfiles
  • 2 disks in RAID1 for tempDB
  • 4 disks in RAID10 for databases

This setup might restrain you in certain areas (like how much space you have for each LUN), but it'll give you much better control over where your I/O lands and especially avoid high LUN queues. It will also be much easier to see bottlenecks, and just upgrade with more disks in the future, or even installing flash disks for tempDB/log if you see that the disks can't keep up with the I/O.

It all of course bottoms down to how much I/O load you're expecting on the system, how often you'll backup the log files (truncate them) and how much of a budget you have.

  • I would argue for tempdb on raid 0 if you can handle the downtime. I do that - Raid 0 on SSD - because I ften need it (gigabytes of use at times in complex aggregation and analysis statements).
    – TomTom
    Oct 22 '14 at 12:55
  • @TomTom Yes, like I mentioned - TempDB is highly situational.. Some databases nearly never touch it, others depend on it all day long.
    – pauska
    Oct 22 '14 at 12:56
  • See I'd create on bit 'all disk' R10 and just carve the various LUNs out of that, I'm really not convinced the difference in performance between that and the 'multi-R1' setup would be much if anything. That said I'd make sure any backup LUNs were on a different array altogether and personally I like to split my logs, data and backup all onto different arrays but that's me.
    – Chopper3
    Oct 22 '14 at 13:02
  • My apologies, I wasn't clear enough with regards to the placement of the files. The MDF files (separate vhd) and the OS/SQL installation files (separate vhd) will be on the first RAID 10 array (LUN10), the log files will be on LUN 20 which is a separate RAID 10 array and the tempdb will be on LUN 30 which will also be on a separate RAID 1 array using 2 disks.
    – dqnet
    Oct 23 '14 at 5:47

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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