Some vendors' storage arrays let you dynamically expand a LUN that you created within the disk pool without incurring any downtime to the SQL Server database whose files reside on that LUN.This feature lets DBAs estimate their disk-space requirements more conservatively and add storage capacity without downtime.
Backup control. As a database grows, so does the amount of time needed to perform database backups. In turn, a longer backup requires a longer backup window. Partial backups—such as database-log-backups— take less time but require more time to restore. Increasingly, upper management is mandating smaller backup windows and shorter restore times for essential applications, many of which access SQL Server databases. SANs can help decrease backup windows and restore times. Some storage arrays can continuously capture database snapshots (i.e., point-in-time copies of data), which are faster to back up and restore than traditional database-backup methods. The snapshot doesn't contain any actual copied data; instead, it contains duplicate pointers to the original data as it existed at the moment the snapshot was created. (For more information about SQL Server 2005's snapshot capability, see "What's New for the DBA in SQL Server 2005?" November 2005, InstantDoc ID 47911.)
To back up SQL Server database data by using snapshots, you'd typically want to put your database in a "ready" state, more commonly called a hot-backup state, for a few moments to perform the snapshot. If you didn't put your database in a hot-backup state, the snapshot could take a point-in-time copy of your database before SQL Server has finished making a consistent database write. Storage-array vendors often use Microsoft's SQL Server Virtual Backup Device Interface (VDI) API to enable their software to put the database in a hot-backup state.This lets the system copy the point-in-time snapshot image to separate backup media without causing a database outage.
Snapshots are minimally intrusive, so you can use them frequently without affecting database performance. Restoring data from a snapshot takes only a few seconds. By using a SAN-connected storage array along with a snapshot capability, DBAs can minimize backup windows and restore times, in part because snapshot images are maintained on distributed disks in the array, instead of on one local disk.
Reduced risks for database updates. Changes to a database, such as SQL Server or application upgrades or patches, can be risky, especially if the changes might cause database outages or worse, database corruption. To test changes without putting the production database at risk, you'd need to set aside an amount of storage equivalent to the size of the production database. On this free storage, you'd restore the last recent backup of that database (typically 1 week old).You'd spend a few hours (maybe even days) restoring the database from tape to disk, applying the changes, then testing to see whether the changes were successfully applied and whether they adversely affected the database. After you verified that the changes were successfully implemented, you'd apply them to the production database.
Some vendors' SAN storage arrays let you quickly clone your database data for testing purposes. Cloning the data takes only a few seconds versus hours to restore it from tape. The added benefit of cloning is reduced disk utilization. Some cloning technology lets you take a read-only database snapshot and turn it into a writeable clone. For testing purposes, the clone consumes far less disk storage than a full backup of a database because only modified blocks of data are copied to the clone database.
When Using DAS Makes Sense
Storing database data in a SAN gives you features not available with DAS, such as local and remote mirroring,data cloning,the ability to share data across multiple hosts, and the ability to capture data snapshots. However, if you don't need these features, storing your SQL Server databases on DAS might make more sense. A SAN environment consists of multiple SAN clients with multiple HBAs on SAN switches connected to storage arrays. If the SAN wasn't properly designed and configured (i.e., to provide redundancy), the storage array or a component on the SAN could fail, so that servers on the SAN couldn't access data on the storage array.
To enable you to troubleshoot storage problems, you'll need to make sure that SQL Server binaries and message-log files stay on the local disk. Storing the message log and binaries on a disk other than the local disk puts the database in a Catch-22 situation, in which a database-access failure caused by a storage-connection failure can't be logged because logging occurs only for the device on which the logs and binaries are stored.
I'm Ready for a SAN. Now What?
If your organization doesn't already have a Fibre Channel SAN switching network in place, iSCSI will most likely give you a greater ROI and minimize your equipment investment. For a Fibre Channel SAN, you need to buy a storage array, Fibre Channel SAN switches,and HBAs.For an iSCSI SAN, you need to buy a storage array, but you can use your existing Ethernet switches and Gigabit Ethernet adapters. To include your Windows servers in the iSCSI SAN, you need only download and install an iSCSI driver for your particular OS. (You can download the latest version of Microsoft's iSCSI driver, Microsoft iSCSI Software Initiator, at http://www.microsoft.com/downloads/details.aspx?familyid=12cb3c1a-15d6-4585-b385-befd1319f825&displaylang=en.) Carving up the storage array and presenting it to your Windows server could get complicated, depending on the storage vendor. As I mentioned earlier, you should discuss your storage requirements with your storage administrator.
Most modern storage arrays let you access LUNs on the same storage array via either Fibre Channel or iSCSI. I've found that many IT environments don't take full advantage of their SAN's features. If your organization already uses a Fibre Channel SAN switching network, you can try out some storage-array features such as cloning and snapshots in a development or test environment. If your organization doesn't have a SAN yet, you can still try some of these features relatively inexpensively by setting up an iSCSI SAN.
Step Up to a SAN
As you can see, housing databases on a SAN can benefit DBAs in various ways. SANs can reduce the pain of sizing storage requirements for databases, enhance overall storage throughput, simplify storage performance tuning, and improve availability. Using a SAN can also decrease backup and restore windows and enables quicker and easier testing cycles and reduced overhead in test storage.The availability of iSCSI removes the cost barriers that have until now inhibited some users from investigating SANs. Now's the time to check out SAN technology and see whether it can improve your database-storage environment.