Editorials

SQL Server and Shared Storage Solutions… SANs…

Featured Article(s)
Using Flash and Javascript to resolve SharePoint dynamic menus issue
If you have ever tried to make your SharePoint or non-SharePoint implementation of the site a little more dynamic you were probably thinking about rotating images or banners. And if you considered implementing them – you will know that because of the crossbrowser incompatibility JavaScript is not the best way to go.

SQL Server and Shared Storage Solutions… SANs…
Some excellent feedback and tips on SAN-type solutions – please – send in your feedback, thoughts and lessons-learned here.

Steven: "The most important thing to remember is that a SAN is just a way connecting disks to a server.

In general use when we say the word SAN we tend to include the disks connected to the SAN but we should not let that confuse how we think about it.

All the rules that apply to JBODs apply to SANs.

This is just lead up to my main point that with SQL server disk I/O performance (and SQL performance) is usually limited by head contention even though proper disk system design can almost eliminate it.

We all (should) know that creating a large RAID5 array using all the disks in a server and then carving out logical drives for data, log, tempdb, etc. is a very bad idea.

It is just as bad an idea on a SAN.

The problem is that the SAN usually adds a layer of opaqueness to the configuration and if the SAN administrator is not DB savvy then the physical configuration will usually not be what you ask for. Even talking about it is confused by using the term "drives" for physical disk drives, an array of disk drives, logical drives as presented to the OS by the array driver and drive letters pointing to a partition on a logical drive.


I have found it helpful to use the word "spindle" when talking to SAN administrators, as in "The transaction log file MUST be on different spindles."

BTW, I have not done the math lately but last time I checked head movement was about almost million times slower than any other part of the server. (For example: average seek time of 12 milliseconds is another way of saying 83 seeks per second. Comparing this to processors running at gigahertz, front side bus with 400 or 800 megahertz, etc.)"

David: "We did some basic speed tests in anticipation of moving one of our servers to our new SAN. Essentially, everything (SQL stored procedures, file system operations, etc.) took twice as long on the SAN as it did to run on local disk. Our network guys now say "oh, that’s because the CPU on the server is doing all the work to talk to the SAN network, so we need to buy special card for the server to offload the SAN processing". Well why didn’t they say that from the beginning?

As the application guy, I’m really frustrated by my Infrastructure guys’ move to a SAN. The only reason we need to change is we’re out of disk space on our server to keep more than 1 day of nightly backups of the database.

They could buy us a 500GB SATA disk for about $250 that would solve the problem, but no, we need to move it to a multi-tens-of-thousands-of-dollars high-tech box that runs slower.

I don’t get it."

Featured White Paper(s)
Java Database Connectivity
Database connections are the lifeblood of enterprise applications, administrating the secure and steady flow of information b… (read more)