Take the 2-minute tour ×
Database Administrators Stack Exchange is a question and answer site for database professionals who wish to improve their database skills and learn from others in the community. It's 100% free, no registration required.

I have a SQL Server connected to a SAN. Our new storage vendor recommends that all LUNs span the entire disk array, which is RAID5. I would normally request 3 separate LUNs (data, log, and TempDB) from the SAN administrator, but given the new vendor's recommendation, is there any point in creating separate LUNs? Or would I see the same performance if everything was in one LUN since it would span all disks anyway?

Great article here, but doesn't quite address my exact situation: http://www.brentozar.com/archive/2008/08/sql-server-on-a-san-dedicated-or-shared-drives/

share|improve this question

4 Answers 4

One thing to consider is that the log files are sequential writes where as the data files are non sequential. That is one of the reasons for separate LUNs. Log files write faster if they are on their own LUN because the spindles don't have to skip around, just write sequential. If you add in a data file then the spindles have to skip around and you lose some performance. I'm hoping I got the right terminology there as I'm not all that familiar with SANs themselves. The idea behind it should be however.

Frequently vendor recommendations are wrong when it comes to SQL Server. Just because SQL Server has different needs than most applications that use a SAN.

share|improve this answer
1  
I think what the OP is saying is that regardless of the LUN, they are all hitting the same spindles. In other words, there is no physical separation for isolated pools of disks. –  Thomas Stringer Feb 25 '13 at 21:20
    
Ahh, I guess what I was saying is don't set it up that way :) have each of the LUNs on different spindles even though the vendor suggests otherwise. If that isn't possible then there is no performance reason to separate them on different LUNs. Although you never know what will happen in the background and at some point in the future if they are on separate LUNs they may be moved to different spindles. –  Kenneth Fisher Feb 25 '13 at 21:52

A lot depends on the SAN, usually you would want to configure different LUNs with different caching, compression, encryption, read-ahead, write through/back policies, priorities, etc. The SQL data files often exhibit different behavior than the tempdb or log files. Access method/network also comes into play as trunking, multi-pathing, and other technologies may or may not work depending on your access method (FC, iSCSI, ..) and infrastructure. You will want to be able to utilize your network to its max with SQL Server as latency and throughput are critical. I have seen cases with networking teaming setup, but only 1Gbps was usable due to other constraints that the client was unaware of. I agree with Kenneth, take vendor recommendations with a large dose of salt, they are quite frequently wrong. SQL Server is a fickle beast, there are very few absolutes, usually just more questions. Asking the right questions (through testing) is really the key.

share|improve this answer

Do not "take vendor recommendations with a large dose of salt", unless they're from the sales or marketing department. Quite the opposite, if you can get access to their technical implementation guys, make friends.

Likely this is one of the new breed appliances that virtualize the storage pool and include auto-tier capabilities. One example would be Compellent. They perform all manner of SAN voodoo such as:

  • Write active blocks of data to Tier 1 storage with performance-optimized RAID levels such as RAID 10.
  • Automatically migrate inactive blocks of data to lower-tier storage with higher-overhead, high-protection RAID 5 or 6.

For the Compellent, storage is divided into 3 tiers with Tier1 being the fastest (SSD or RAID 10) through to sluggish Tier3 which comprises 7k SAS disks. I've not used one of these in a production environment as yet but do have access to one, which I hope to be able to run some tests against.

I confess to being both intrigued and fearful of the auto-tier features, which on paper sound wonderful but in production may be problematic. The first example that occurred as potentially scuppering the auto-tier mechanism was database backups. There you have a repeating high write target which may fool the tiering mechanism into moving the blocks to a high performance pool, potentially pushing out data that should be there.

To the original question:

...is there any point in creating separate LUNs?

Probably not, no. Make the use case clear to the vendor to be sure but if it is a Compellent type device, I don't believe you gain anything from splitting your LUNs.

share|improve this answer

Is there any point to separate LUNs? Almost always. Otherwise you end up overloading the LUN queue on the Windows server. And experiencing qfull conditions is painful, regardless of the OS, virtualization, or storage platform

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.