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.
It is very cool and I’m sure lots of organizations will think the Availability Groups feature is right for them. until that is, they see the potential price tag that comes with it, Multiple Enterprise Editions under the per core model, ouch that’s not cool at all.
It’s a shame that a somehow restricted version isn’t in Standard Edition. Oh well, maybe in the next version
I think it’s fair to keep Availability Groups expensive from a licensing perspective. They really expand the options you have of how to use storage, and for people who write their own software the potential cost savings in development time for scaling out reads could also be compelling. The ability to also include failover clusters and integrate AlwaysOn with disaster recovery over different subnets will also be huge for some customers in terms of value.
But I do agree that for many, the value proposition won’t make it worthwhile yet. I don’t expect to see “plain” failover clustering or mirroring or logshipping stop being used at all!
I do think that the main crowd this impacts is the Senior DBA group, and anyone who wants to become a Senior DBA. There’s going to be a lot of focus on understanding this feature and knowing when and where it gives the value needed, I think. But it won’t be everyone’s cup of tea until the new pricing sinks in 🙂
Sideburns never went out of fashion – the bigger the chops, the better. LOL
I feel like I’m the only one who disagrees with the current trend. I can’t imagine being a good DBA/DB Architect without knowing everything about servers, server architecture, enterprise storage, SAN administration, etc. I also don’t like that there are now DBA’s and Developers. When did taking an algorithm, writing it in TSQL so that it can run in parallel using massive resources efficiently, so that it can satisfy the requirements of thousands of users instead of just one, make you not a developer? We’re more like SQL garbage men – we clean up terribly bad code only when it rises to the level that someone notices how bad it is. Everything is written by front-end developers with no knowledge of the details of SQL Server. We’re not even invited to the “developer” meetings.
I’m struck by a couple of things about your comment. You seem unhappy that there’s a difference between DBAs and developers, yet you also seem to have a lot of animosity towards developers.
My own experience is that I only could make things better when I stopped expecting developers to invite me to meetings, and just started working with them in ways where it was natural for me to be there. A big part of that was getting over a lot of the negative talk about “them” and seeing things from their perspective, too.
Hey SQL Rob,
I’m actually used to being the senior app and web developer, the senior DBA, AND the ranking network and server administrator. I STILL manage to get left out of meetings. Don’t ask me how though! 🙂
So glad I found this site and the accompanying videos. I’m looking at a company now that can’t find someone who knows the infrastructure side of things involving Windows clustering but wants to move up to Always On HA. They say they are getting nothing but SQL DBAs. I was the second on a two man team at the end of 2013 rolling out a 4 host 2012 cluster with about 30 total VMs that used a 24TB Synology SAN for central storage, iSCSI, NIC teaming, and MPIO. It is so much fun watching 15 servers Live Migrate between hosts with people on them and nobody but us is the wiser.
We didn’t implement Always On because we’d just moved up to SQL 2012 from 2005 and only had two database instances running, one each on two machines. So it will be great picking up technique from this site and others.