November 6, 2008 at 9:42 am
I'm by no means a SAN expert but it seems from what you guys are saying that in the case where a SAN's resources far outnumber the resources actually required by the infrastructure, then the SAN is a winning choice. Also the point Steve makes about future scalability considerations is a very strong argument.
However, if the size of the SAN is roughly comparable to the size of the infrastructure it is supposed to serve - ie. if the SAN is roughly equal to or less than the grand total of disk, memory etc. resources required by an organization - then that's trouble.
Am I missing something?
__________________________________________________________________________________
SQL Server 2016 Columnstore Index Enhancements - System Views for Disk-Based Tables[/url]
Persisting SQL Server Index-Usage Statistics with MERGE[/url]
Turbocharge Your Database Maintenance With Service Broker: Part 2[/url]
November 6, 2008 at 9:56 am
TheSQLGuru (11/6/2008)
Marios Philippopoulos (11/6/2008)
Would all 1024 drives be 'seen' by the same SQL server instance and shared by all other SQL instances? How does that help with IO throughput? Isn't contention a problem in this scenario?You can create and expose LUNs in whatever manner is optimal for your environment.
We can go back and forth for hours or even days on this. Unfortunately I don't have that kind of time. If you can push the "I believe" button that SANs CAN provide incredible performance benefits that cannot be achieved by DAS - great. If not, either hire someone to come in and give you some mentoring or go back to "hating SANs". 😉
First of all, I was joking.
Secondly, no one needs your opinion if you don't want to give it.
__________________________________________________________________________________
SQL Server 2016 Columnstore Index Enhancements - System Views for Disk-Based Tables[/url]
Persisting SQL Server Index-Usage Statistics with MERGE[/url]
Turbocharge Your Database Maintenance With Service Broker: Part 2[/url]
November 6, 2008 at 10:30 am
I must have missed the smiley that indicated you were joking. As for resources required, the main issue with that statement is that almost everyone simply uses SIZE as the 'requirement' for IO needs. But IO 'performance' is about spindle count, spindle speed, IO path, cache, etc. Those can often best be achieved with a SAN. If you need 10TB of space, you can accomplish that on 10 direct attached 7200RPM SATA drives - and your performance will be horrible. Or you could put that 10TB on a SAN with 100 15000 RPM SCSI-type drives and 64GB of front-side cache and 4 HBAs and get drastically better performance.
Best,
Kevin G. Boles
SQL Server Consultant
SQL MVP 2007-2012
TheSQLGuru on googles mail service
November 6, 2008 at 11:34 am
TheSQLGuru (11/6/2008)
I must have missed the smiley that indicated you were joking. As for resources required, the main issue with that statement is that almost everyone simply uses SIZE as the 'requirement' for IO needs. But IO 'performance' is about spindle count, spindle speed, IO path, cache, etc. Those can often best be achieved with a SAN. If you need 10TB of space, you can accomplish that on 10 direct attached 7200RPM SATA drives - and your performance will be horrible. Or you could put that 10TB on a SAN with 100 15000 RPM SCSI-type drives and 64GB of front-side cache and 4 HBAs and get drastically better performance.
Thanks, I have a question on how to judge a SAN's performance (what to use as a baseline etc.), but perhaps this can be reserved for a separate thread.
__________________________________________________________________________________
SQL Server 2016 Columnstore Index Enhancements - System Views for Disk-Based Tables[/url]
Persisting SQL Server Index-Usage Statistics with MERGE[/url]
Turbocharge Your Database Maintenance With Service Broker: Part 2[/url]
November 6, 2008 at 12:33 pm
Marios Philippopoulos (11/6/2008)[hr
Thanks, I have a question on how to judge a SAN's performance (what to use as a baseline etc.), but perhaps this can be reserved for a separate thread.
Another thread is probably appropriate - but my 2 favs is avg disk sec/read and avg disk sec/write for the appropriate physical disks. Note also that you can use SAN monitoring tools to determine how they are performing as well.
Best,
Kevin G. Boles
SQL Server Consultant
SQL MVP 2007-2012
TheSQLGuru on googles mail service
Viewing 5 posts - 31 through 35 (of 35 total)
You must be logged in to reply to this topic. Login to reply