Go Premium for a chance to win a PS4. Enter to Win

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 536
  • Last Modified:

SQL Server 2008 SAN Configuration

I have been nosing around the web, trying to find good information on best practices for SAN Configuration for supporting SQL Server databases. The papers I am finding are antique by technology standards [a few years old]. So here goes, ...

I would appreciate any SOLID information concerning this topic. References?

Consider the following scenario. Imagine that you have a brand new EMC or NetApp. You can configure it anyway you want, but your primary interest in is making sure that SQL Server has every advantage in terms of data access. According to the vendor, there is no longer a requirement for storage isolation -- you can basically put whatever you want wherever you want and get performance.

Some of the basic rules should/may still apply. For example, you probably don't want to share devices between data, log, backup files. [This may or may not be true from your point of view. Experts sound off!]  

I have seen people sharing a RAID array that is split -- I am leary of having data and log on the same physical devices. Picture 300GB array with 15 drives -- 200GB is used for data and identified as one logical device -- the other 100GB on each device is used for log. This seems like a really bad idea to me, even on a SAN.

It also makes sense to me that you might want to employ another database best practice by way of analogy: Application Isolation. By this I mean that you would not want to co-locate apps on the same devices to allow you to avoid having two production systems down when only one should be.

I am only vaguely aware of SAN architecture in terms of paths between the controller/cache system and the actual DEA's that contain the drives, but have heard that you may want to ensure that two major applications do not share the same physical path to the drives.

I have also heard that files that are furthest [physically] down in a series of DEA's will be slower for data access than those that are closer.

This post has basically two objectives: 1. How do you organize a SAN in a sensible manner for SQL Server? 2. What are the specifics that can help and hurt in terms of where the data, log, tempdb, etc., are located.

Thanks for any light you can shed on the topic.
0
Melaleuca
Asked:
Melaleuca
1 Solution
 
Chris MangusDatabase AdministratorCommented:
I've had several databases on a SAN and configured them the same way I would have, had they been actual attached local drives.  Put your data and log files on different spindles.

Physical path to the drives usually doesn't matter because most HBA's use fiber channel.  Physical location within the SAN doesn't matter either.  You may be talking about a difference of nanoseconds as far as whether data access is slower or faster.  In other words, it doesn't matter.  

When putting multiple SQL Servers on the same SAN I just kept myself aware of what systems were sharing which spindles.  I never mixed two large production systems, never had LUN's across the same spindles.
0
 
MelaleucaAuthor Commented:
Giving good scores because a DBA colleague left the thread open on corporate account and now I need to ask another question.
0

Featured Post

New feature and membership benefit!

New feature! Upgrade and increase expert visibility of your issues with Priority Questions.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now