The role of the Infrastructure DBA

Do you have someone performing an Infrastructure DBA role within your organisation? Do you realise why today you now might need one?

This is a re-post of a blog article I’ve posted at (link)

When I first started working with SQL Server there were three distinct roles in the SQL Server virtual team: developer, DBA and sysadmin.


In my simple terms, the developer looked after the “code”: the schema, stored procedures, and any ETL to get data in, out or updated within the database. They could talk in business entity terms about Customer numbers, Product codes and Contract line items. Whatever else happened in the SQL Server stack didn’t really bother them as long as their code worked.

The DBA knew how SQL Server worked, they’d install the software, create databases, manage indexes and SQL Server Agent jobs, do backups and restores. They’d sometimes write ad-hoc reports so knew which columns held key data but how every bit of database logic worked wasn’t of interest to them. DBAs did however care about the design of the database and the server hardware. Making sure the server hardware was of the right spec and configuration was also another interest for DBAs, along with doing everything to avoid getting called out at 2am.

The sysadmin could never do anything right. He always wanted downtime for Windows patches or firmware upgrades, however, as long as everything got built right and worked we never had to bother him, until a SAN got installed. Then we were never quite sure if he actually knew what he was doing and were pretty sure it wasn’t configured properly.

Ok, there maybe some exaggeration there but with dedicated physical servers those three roles were fairly common throughout the 2000s. Nothing but SQL Server could affect the performance of our database platform, and more importantly with the sysadmin at our side everything was in our control. Equally as important was the fact that our monitoring results were true, no one else’s workloads affected the results.

Role forward to 2010

By the end of 2010 virtualisation and SANs are regularly deployed to host both production and non-production SQL Server environments. The dependency between an instance of SQL Server and physical hardware and disks has been broken, we can create new servers and allocate them storage and resources on demand. However, as the diagram below shows this agility has come from the practice of pooling then sharing our physical resources.

New_stack_1What we must now cater for in our SQL Server is that although hardware resources might be allocated to us, the platforms they come from aren’t dedicated to us. The SAN our data is stored on might also store the Exchange mail server’s data, the virtualisation host server our database server runs on might also be running a web server.

The Infrastructure DBA

This new world brings new responsibilities to a SQL Server administrator, in fact it brings a new role to the SQL Server virtual team. To be able to confidently ensure that SQL Server delivers the performance your applications need in a virtualised world you now need someone who understands:

  • the database’s demands of SQL Server
  • SQL Server’s demands of the server
  • SQL Server’s demands of the storage system
  • How the hypervisor is configured, shared and works
  • How the SAN is configured, shared and works  

Is this because we don’t trust the virtualisation or SAN admins, well I’d hope the answer is no.

However, if we’re to understand how SQL Server is performing, or needs to be configured to perform, when it’s using shared components then we need to know as much about our SAN storage layout as we do the logical TempDB layout, if not more so. Configuration changes can be made which we have no control or influence over which can bring SQL Server to its knees.

As well as defending SQL Server against threats to its performance the Infrastructure DBA can bring new features to the SQL Server toolkit. Infrastructure services such as virtual server snapshotting, SAN snapshotting and SAN-to-SAN replication could be invaluable in some environments. By knowing what the infrastructure you’re using is capable of these feature become options to you.


We will always need application code developers, SSIS junkies, production DBAs, sysadmins, virtualisation admins and SAN admins, but now there’s a place at the table for someone who knows enough about each of these to keep the SQL Server ship sailing, at the right direction and at the right speed.

Welcome to the Infrastructure DBA.


2 thoughts on “The role of the Infrastructure DBA

  1. Jason

    Excellent article! I’m definitely what you term an Infrastructure DBA. We have great System Admins and Virtualization Admins where I work, but I’m definitely deeper into SAN and Hypervisor administration and troubleshooting than I think the average DBA is. I started just in time to help build out a massive Vmware / NetApp virtualized datacenter with the company architect and infrastructure leads. We have 9 large DB’s virutalized, and those DB’s are sharing SAN disks with our global Exchange environment as well as over 40 virtualized web and application servers. It often falls on me to ensure that the DB servers are not contending with the other VM’s – or if they are, to help identify the cause and correct.

    1. gavinpayneuk Post author

      Hi Jason,

      You’re an example of why someone in the SQL Server team needs to know what’s going on with the VMware and SAN infrastructure in order to ensure your database servers aren’t getting a raw deal. Some SAN admins just look at I/O workloads and don’t understand the application or platform behind those, I bet you add great value to their way of working!


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s