There is always a performance benefit from using separate, non-shared spindles whether these are locally attached or in a storage array. Do you actually need the performance benefit that they provide? That’s a different question. The point here is that just because it’s on SAN doesn’t mean it’s fast or will give you the IOPS you need. Often, the disks behind the LUNs you are given are shared by many, many other systems and applications. This could be fine if the LUN is striped across hundreds of disks, but if they are only a handful of disks behind the LUN and lots of systems sharing those disks, then performance will suffer greatly. Work with the storage guys and stress to them how important IOPS are.
J From: [email protected] [mailto:[email protected]] On Behalf Of Sean Martin Sent: Sunday, February 2, 2014 12:15 AM To: [email protected] Subject: Re: [mssms] SQL Server Sizing It may ultimately depend on your backend storage and how your data stores are allocated. There could still be small benefits to using separate disks even if they reside on the same data store. Separating the sequential and random IO through separate virtual adapters can yield better performance. You even benefit from slightly more granular capacity management by separating your logs from your DBs. - Sean On Feb 1, 2014, at 6:16 PM, Brian McDonald <[email protected]<mailto:[email protected]>> wrote: What is the recommendation if the server is virtual and the disks are on a SAN? ________________________________ From: [email protected]<mailto:[email protected]> To: [email protected]<mailto:[email protected]> Subject: RE: [mssms] SQL Server Sizing Date: Sun, 2 Feb 2014 00:39:52 +0000 And remember, for the multiple “disks”, unless they are truly separate, unshared, physical spindles (or sets of spindles) for each separating them has zero impact on performance and is just a waste of disk space. LUN != physical spindle(s) RAID != physical spindle(s) J From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Marcum, John Sent: Friday, January 31, 2014 1:16 PM To: [email protected]<mailto:[email protected]> Subject: RE: [mssms] SQL Server Sizing What's the 5120 number representing? I usually do something like 75Gb C:, 75Gb SQL data, 25 SQL Logs, 500Gb ConfigMgr ________________________________ John Marcum Sr. Desktop Architect Bradley Arant Boult Cummings LLP ________________________________ From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Brian McDonald Sent: Friday, January 31, 2014 12:43 PM To: [email protected]<mailto:[email protected]> Subject: RE: [mssms] SQL Server Sizing Both scalability, performance and future expansion needs. I’m not sure how to break down the Disk Size for the TempDB, .db files and Transaction log files with the estimate you’ve provided below. The Primary Site in a hierarchy (up to 25k clients) w/ co-located sql server). Seem reasonable? Initial size 5120 # Clients 577 DB size pr. client 5 # processors 4 # cores 2 Memory
