As a consultant, I get to meet many varied SQL Server professionals on a regular basis. One of the most common conversations we've had over the last few years surrounds the loss of control the DBA has experienced due to a couple of advances in technology.
The first of these is the advent of storage area network (SAN) storage, which has become significantly more prevalent in recent years. The advantages of using SAN are clear, particularly for the storage administrator - better utilization of storage, centralized management of shared storage, potential performance gains from caching and using a dedicated network for I/O traffic, high availability with SAN snapshots - the list goes on. The SAN vendors are understandably quick to focus on these advantages and the message seems to be that the SAN will solve all your storage and I/O problems. Some even suggest you can stop taking normal SQL Server backups as the SAN will recover everything for you!
The challenge for the DBA is to get an understanding of what is happening with your data. I often ask some simple questions like, "What RAID level is your SAN configured with for SQL Server storage?" or, "Can you still do Point in Time Recovery as you can with SQL Server backups." The answer is often a worrying, "I'm not sure, I'll ask the storage administrator." In the past, a DBA knew his storage, particularly his DR strategy, like he knew his own children. The concept of handing over some of this control to someone else was unthinkable; yet, this is what has happened in a lot of cases. The answers they receive are often surprising to the DBA, like all their data is stored on RAID 5, which can lead to poor write performance for the database.
The second advance is virtualization. Once again, the advantages are clear - addressing server sprawl, reducing power consumption, improved resource management for servers, high availability - again, the list goes on. IT management tends to be very keen to implement virtualization as far and as wide as possible. DBAs have been cautious about this, as there were concerns over increased overhead to the SQL Server. The initial deployments tended to be within the DEV, UAT and test environments; however, improvements in virtualization technology, cheaper hardware, and pressure from budgets means many more production servers are now heading the same way.
In this case, I ask the questions such as, "What else is running on the same virtual host?" and, "Do you know how CPU resource and memory ballooning is configured and controlled in this environment?" These questions are often quickly referred to the virtualization administrator, and the answers can be very worrying when the DBA realizes they may have been allocated certain resources which can be reduced automatically when other servers need them, or that some other resource-hungry applications are running on the same physical host.
Where there was one administrator in the past, now there are three or more who need to work together - another, unfortunately, rare event in a lot of IT departments. It is not the job of the other administrators to understand how to configure the environments for SQL Server, nor should it be.
The only solution is to get involved at the design stage. So many DBAs are just handed the server when it's time to install SQL Server, and this is far too late. It is important to question when buying any new technology - "Okay, I'm getting all this great stuff, but what am I losing?" If it's already implemented, it can be difficult to change, but having an awareness of how it all works means you either can change when it is possible, or have a readymade excuse when users complain about performance!
Let me know your thoughts. Email: iain.kick@quest.com, follow me on Twitter: www.twitter.com/iainkick or visit my blog: www.iainkick.com