InstantForum.NET v4.1.4SQLServerCentralhttp://www.sqlservercentral.com/Forums/notifications@sqlservercentral.comSun, 08 Nov 2009 09:10:59 GMT20http://www.sqlservercentral.com/Forums/Topic606537-146-1.aspxSure. TonnesTry these for starters:[url]http://www.microsoft.com/technet/prodtechnol/sql/2000/maintain/sqlIObasics.mspx[/url][url]http://www.microsoft.com/technet/prodtechnol/sql/2005/iobasics.mspx[/url][url]http://www.microsoft.com/technet/prodtechnol/sql/bestpractice/pdpliobp.mspx[/url][url]http://www.microsoft.com/technet/prodtechnol/sql/2005/physdbstor.mspx[/url]Wed, 26 Nov 2008 07:45:26 GMTGilaMonsterhttp://www.sqlservercentral.com/Forums/Topic606537-146-1.aspxHi Guru's, Is there any whitepaper or document released by MS which will help SQL DBA's to understand the best practice for which RAID to choose, what are new technologies in RAID, SAN. How to find, troublshoot etc...Wed, 26 Nov 2008 00:34:30 GMTSakthivel Chidambaramhttp://www.sqlservercentral.com/Forums/Topic606537-146-1.aspx[quote][b]GilaMonster (11/23/2008)[/b][hr]don't slice a LUN and give it to the data files and slice another from the same disks and give it to the log files[/quote]this is very important, if you do this you may as well have sql server store all its files on the same logical driveMon, 24 Nov 2008 10:44:44 GMTPerry Whittlehttp://www.sqlservercentral.com/Forums/Topic606537-146-1.aspxGotta agree with just about everyone here. Treat the physical disks in the SAN the same as you would internal disks, when it comes to SQL performance and disaster prevention. The only SQL thing I'd put on a SAN that wasn't handled that way, would be backup files.Mon, 24 Nov 2008 09:06:33 GMTGSquaredhttp://www.sqlservercentral.com/Forums/Topic606537-146-1.aspxEven if you don't, as others recommend, have 'control' or even input as to the configuration of the SAN for your SQL Server storage needs, you probably still should create separate drives on the various LUNs you are provisioned. There is the possiblity that those LUNS ARE on separate disks, controllers, switches, etc which will provide benefits and reduce possible performance choke points. If none of the above is true, at least it shouldn't cause things to be markedly worse. :)Mon, 24 Nov 2008 08:36:55 GMTTheSQLGuruhttp://www.sqlservercentral.com/Forums/Topic606537-146-1.aspxBear in mind that a san doesn't automatically make things fast. To quote a friend, 'There's no magic san dust'Even with a san (or especially with a san) you need to follow IO best practices. Appropriate raid levels, dedicated disk arrays, aligned partitions, etc.The MS best practice for sans is to never share disks between disparate workloads. ie, don't slice a LUN and give it to the data files and slice another from the same disks and give it to the log filesSun, 23 Nov 2008 09:46:18 GMTGilaMonsterhttp://www.sqlservercentral.com/Forums/Topic606537-146-1.aspxYes and no ;-)I've seen this happen in a few different places. Generally, the storage admins I've worked with have been top notch. They understand best practice for SQL when you are talking about normal RAID arrays. The issue starts to get more complicated when you factor in new storage technologies and the best way to share storage across the IT though.As I mentioned, with things like virtual disk/vRaid technologies, this best practice is no longer so clear cut. While the vendor may recommend this or that strategy it has to be balanced against the fact that other servers in IT such as Exchange, ESX, clusters, DB's are going to share that storage. Throw in tight budgets and concerns about overall best use of capacity and you have an array of different competing factors that must be worked out.Sun, 23 Nov 2008 07:42:34 GMTRob Symondshttp://www.sqlservercentral.com/Forums/Topic606537-146-1.aspx[quote][b]Michael Earl (11/21/2008)[/b][hr]Your admin should be carving these out of individual physical disk arrays. They often really need different RAID configurations.[/quote]couldnt agree more, does your SAN admin understand the RAID config required for SQL serverSun, 23 Nov 2008 03:17:42 GMTPerry Whittlehttp://www.sqlservercentral.com/Forums/Topic606537-146-1.aspx[quote][b]Michael Earl (11/21/2008)[/b][hr]You are correct in that you lose the benefit if the SAN admin is carving three partitions out of a LUN that is using the same physical drive array.Of course, your initial assumption "should" be wrong. Your admin should be carving these out of individual physical disk arrays. They often really need different RAID configurations. Log files have lots of sequential writes, data files have lots of reads and non-sequential writes, and backups - well it is often best to put those on cheaper, slower drives so you can afford to retain a few days or weeks of them without breaking the bank.The best place for information on how the SAN should be configured is your SAN vendor. MSSQL configurations are extremely common these days. They should have done enough of these to know what configurations will suit your needs - assuming you give them enough information. Every SAN solution seems to be a bit different, so talk to your vendor.[/quote]I agree. That's how we did it at my last place, and will be doing here in a few months with our new data center. For instance, with 20 drives in the array, drives 1-4 can be drive E for logs, drives 5-8 can be drive F for data, drives 9-12 can be drive G for indexes, drive 13 & 14 can be drive H for backups etc .....Fri, 21 Nov 2008 09:58:45 GMThomebrew01http://www.sqlservercentral.com/Forums/Topic606537-146-1.aspxYou are correct in that you lose the benefit if the SAN admin is carving three partitions out of a LUN that is using the same physical drive array.Of course, your initial assumption "should" be wrong. Your admin should be carving these out of individual physical disk arrays. They often really need different RAID configurations. Log files have lots of sequential writes, data files have lots of reads and non-sequential writes, and backups - well it is often best to put those on cheaper, slower drives so you can afford to retain a few days or weeks of them without breaking the bank.The best place for information on how the SAN should be configured is your SAN vendor. MSSQL configurations are extremely common these days. They should have done enough of these to know what configurations will suit your needs - assuming you give them enough information. Every SAN solution seems to be a bit different, so talk to your vendor.Fri, 21 Nov 2008 08:28:45 GMTMichael Earl-395764http://www.sqlservercentral.com/Forums/Topic606537-146-1.aspxFor critical production systems, I insist that the SAN administrator create dedicated RAID groups / LUNs for each of the purposes you describe (except maybe backups...). Not only does it make I/O performance issues easier to diagnose if the RAID groups aren't shared, but you then don't have the issue of potentially losing multiple volumes in the event that you lose more than one disk in a RAID group. Maybe I'm just an old stick-in-the-mud, treating a SAN in much the same way I would local disk. I don't trust virtualization of production systems either for much the same reason.Fri, 21 Nov 2008 08:28:22 GMTloachhttp://www.sqlservercentral.com/Forums/Topic606537-146-1.aspx[quote]It seems like things aren't so clear when you are using a SAN and your storage administrator is simply carving LUNs out of a large disk group. Chances are high that the SAN disks on your server are operating across the same physical sets of spindles. I imagine this is even more the case when your SAN is using something like virtual disk/vRaid technology. [/quote]I would think if you are putting your files on a SAN it should not matter how it is managed. The SAN should intelligently migrate your files based on their usage stats...depending on what type you are using.This question could always be better resolved by testing a SAN forcing your files onto separate physical disks / disk arrays versus just letting it manage where your files land on a LUN. Anyone got a SAN sandbox?Fri, 21 Nov 2008 08:24:31 GMTlrhyrnehttp://www.sqlservercentral.com/Forums/Topic606537-146-1.aspxBest practice is to split up data, log and backup files to different disks. This makes sense when you are using internal storage. This configuration gives you separate disk controllers and separate spindles for each which results in significantly reducing IO contention due to different workload characteristics.It seems like things aren't so clear when you are using a SAN and your storage administrator is simply carving LUNs out of a large disk group. Chances are high that the SAN disks on your server are operating across the same physical sets of spindles. I imagine this is even more the case when your SAN is using something like virtual disk/vRaid technology. I still break data, log and backup files onto separate disks. But I'm wondering at this point what that is actually getting me? It seems like the benefit on the physical IO side is somewhat reduced when using a SAN. What are the benefits on the SQL or OS side of keeping these on separate logical disks?Fri, 21 Nov 2008 08:01:24 GMTRob Symonds