SAN Storage Best Practices for SQL Server

I bet you’re here because you don’t trust your SAN administrator.  The SAN admin’s been telling you everything’s fine, and that it must be a SQL Server problem, right? Well, maybe – but to find out, you’re going to have to crack open some books – or blog posts, at least.

Testing Your Storage Throughput

Click for more information about Brent's online storage course

Click for more information about Brent’s online storage course

Start by getting a rough idea of your storage performance compared to other storage – and what SQL Server needs:

Testing with the free CrystalDiskMark – this is the easy button of storage tests.

How to Test Your Storage with SQLIO – this isn’t as easy as CrystalDiskMark, but it’s more accurate and more powerful.

Microsoft Fast Track Data Warehouse Reference Architecture – if you think the title is long, wait til you try to read the entire post. Actually, don’t – just do a control-F in that doc to find the phrase “Designed with a Balanced Hardware Approach” and read until you hit the “Updating the SMP Reference Calculator Spreadsheet for a new Hardware Configuration.” You’ll understand SQL Server’s Maximum Consumption Rate – basically, you need to be able to pull at least 200MB/sec of data per core to keep SQL Server busy. Otherwise, your SQL Server is just sitting around twiddling its thumbs at 5-20% CPU while queries are running – and while that sounds like a good thing, it’s not, because you’re paying licensing by CPU.

If you’re not getting at least 200MB/sec of storage throughput, it’s time to dig in and find the bottleneck. Keep reading.

How SQL Server Connects to Storage (Pathing)

The term SAN gets misused a lot because it really means Storage Area Network – the communication pipelines between your server and a magic black box called a SAN controller.  That controller is the configurable hardware that manages RAID levels, caching, and more.  Here, we’re talking about how we plug your SQL Server into the network (SAN) itself, and how it gets there is called pathing.

How SQL Server Uses Storage

The relationship between memory (cache), data files, log files, and TempDB is like your Facebook status – it’s complicated.

Vendor-Specific SAN Best Practices for SQL Server

SAN gear is notoriously difficult to configure, but thankfully, storage vendors put a lot of work into writing good documentation on how to set up their gear for SQL Server.  Read this stuff, and believe me, there’s some fantastic tips in here that can make all the difference between good performance and bad.

Here’s the most common vendor document repositories:

Look for document titles that include the words setup, configuration, best practices, guidelines, and so on.  These are the least likely to be marketing.  If the document isn’t at least 10 pages long, skip it and keep looking – short documents tend to be marketing fluff.  The longer documents will tell you the right RAID type to use for data files, log files, and tempdb, plus much more like stripe sizes and cache configurations.

When you find the right one for your storage gear, hand the guidelines to your SAN administrator – that’s your best chance to get the right settings.  Ask them to show you the SAN management software to verify each of the settings listed in the manufacturer’s guidelines.

General SAN Best Practices for SQL Server

If you can’t find guidance for your particular make/model of storage, let’s talk about general best practices that work with most types of storage.

  • SQL Server on a SAN: Dedicated or Shared Drives? – a reader asked for help configuring their blades and NetApp SAN.
  • Automated Tiered Storage for Databases – the differences between SAN-level tiering and drive-level tiering, and what you should pick for SQL Server.
  • Putting SQL Server Data and Log Files on the Same Drive – sometimes it makes sense, and I explain why.
  • SQL Server Setup Checklist – Now that you’ve learned about the basics of SQL Server storage, it’s time to put together a SQL Server.  We’re not just going by best practices here – we’re going for real-world maintainable performance.  I tell you what changes to make before & after the install, and some of these have a big payoff in storage performance.  Make sure to enable Instant File Initialization, for example, and I explain how in the checklist.
  • SQLCat Troubleshooting Logs - Microsoft’s SQL Customer Advisory Team says, “With respect to #1 our recommendation for response time on the log device should be in the range of <1ms to 5ms.”

Getting Help from Brent Ozar Unlimited

We’re here for you.  Brent Ozar Unlimited is a boutique consulting firm focused on understanding your environment and strategy. We partner with you to objectively identify pain points and develop remedies that align to your business goals.  Your experience comes first; we share our knowledge and expertise to help you. Learn more about our SQL Critical Care®, or check out our SAN training videos.

css.php