Professions go through phases. Some skills are highly valued for a while, then go out of fashion. Just like leg warmers and skinny jeans, some skills come back into style when you least expect it.

Database Administrators Started Out in the Server Room

In the early days, most database administrators started out by racking servers. Some DBAs wrote some application code, but most DBA jobs were classified as being part of infrastructure teams. In the old days, Senior DBAs often worked with Active Directory and also helped manage domains.

This changed gradually over time. Database development emerged as its own profession, distinct from general application development and database administration. Business intelligence branched off. But database administration itself evolved and became more application-centric.

More Knobs and Dials Made DBAs Software Technicians

Over time, performance tuning has become increasingly complex. Hardware tuning is now just one of many ways to make an application run faster— we have a myriad of settings in the operating system and in SQL Server to tune performance for a given workload.

This change in breadth made database administrators focus increasingly at the Operating System level and above. The rich instrumentation in SQL Server caused DBAs to be increasingly valued for skills at interpreting results from dynamic management views, rewriting queries, and tuning indexes.

SAN and Virtualization Increased Specialization in IT

Changes in the way we manage storage and servers also shifted the role of the DBA. Infrastructure teams are larger and more specialized. In many companies there is a central IT function for the purchase and management of hardware and operating system licenses. At the extreme end, in some environments the database administrators have little insight into what host their virtual machine is connected to, and may not be aware of what type of storage is in use. Some DBAs don’t have direct access to their Windows Servers.

This very specialized DBA knows a lot about SQL Server, but not much about system administration or Windows domains.

SQL Server 2012 Will Change the Way DBAs Think

The AlwaysOn Availability Group feature in SQL Server 2012 is about to change the style again. This feature doesn’t make the DBA any less specialized, but it has components that make it cool for DBAs to get back in touch with their inner sysadmin.

First of all, this feature is hot. Readable secondaries can help scale out an application with very minimal software development costs. Lots of organizations will want to know if this feature is right for them.

Secondly, consider this: every DBA needs a sandbox that can be flattened and rebuilt at will. This sandbox is for testing new features and practicing configuration. In the past, domain membership wasn’t needed to test most important SQL Server features. You can test replication, database mirroring, and logshipping simply by installing multiple instances into a single virtual machine (or onto Windows 7, for that matter) and granting permissions using local accounts.

With AlwaysOn Availability Groups, things are more complicated. To fully test the feature, you will need to enable the failover clustering feature on multiple SQL Server hosts. This means that you need:

• Windows Server Enterprise Edition as the operating system
• The Windows Server instances must be part of a domain

It’s also useful to be able to provision IPs for the environment and create individual service accounts. Voila— your sandbox environment needs a domain controller.

Test Environments Will Get Bigger

My sandbox used to be just my laptop, which hosted a few virtual machines. My VMs simply ran different versions of SQL Server— I’d start up whatever VM I needed for my testing, and only run one VM at a time.

All of that is changing now. To test and demonstrate Availability groups, I need to run at least one domain controller and five additional VMs for SQL Server instances. (There’s no shortcut for this, by the way— each replica in an Availability Group needs its own Windows server installation.) I’ve found that I need at least 16GB of RAM and 4 processor cores minimum to run a light test workload on that full group.

This expanded my sandbox environment quite a bit. It also expanded my knowledge: I’ve learned that sysprep is still required for Windows 2008R2 when cloning machines that will join a domain, if you want to successfully add them to a failover cluster. (There are some blog posts out there which say differently!) I also now know that a single cluster can’t contain both full and core installations of Windows Server, either— it’s one or the other.

More Senior DBAs Will Be Managing Domains Again

… but these domains will be private test environments, not production.

As SQL Server 2012 is released and becomes more mainstream, Senior DBAs everywhere will be configuring more complex sandbox environments than they’ve ever used before. They’ll be interacting with parts of Windows that they always took for granted, and learning about how SQL Server integrates into the OS.

Of course, not everyone will adopt the Availability Groups feature in production. It’s an expensive feature, and not every application justifies the cost.

But Availability Groups do raise the bar for Senior SQL Server DBAs. It’s going to become very valuable to know and demonstrate what the feature does, whether it’s worth the cost for a given application, and what the alternatives are.

To get to know that well, Senior DBAs will be renewing their interest in systems administration.

And I, for one, couldn’t be happier.

Want to get started now? Check out Brent’s blog post on How to Install Availability Groups.