In previous blog posts I have explored the relevance of the DBA position itself in business and the unique ways that SQL Server DBAs tend to fall into their positions. After mulling over those topics I found myself considering the varying organization dynamics I have encountered with customers of various sizes and the ways DBAs tend to work with each other and other stakeholders in the business.
First, let’s consider the team size.
Many SQL Server DBAs in particular are being thrown into the position as an afterthought, often after a crisis of some sort convinced the corporate leaders that SQL Server was not as self-managing as they imagined. And in those cases there are lots of lone rangers out there. At Idera we sympathize with your plight and seek to help by building online community, like this one, where you can reach out to colleagues with similar issues. And we have ramped up production of free tools because we know it can take time to convince the corporate budget departments that you need tools to get the job done.
I recall a spreadsheet provided by Meta that would estimate exactly how many DBAs you needed depending on criticality, size, transaction volume, and vendor. The typical ratio for SQL Server seems to have hovered around 40:1 for some time, but the variation can be huge. (If you are a DBA handling 100 or more instances then be sure to research these industry standards before your next review. :-))
If you are in an organization large enough to have a DBA team then the next factor to consider is organization, or lack of one. Some DBA teams are loose organizations that simply tackle problems and tasks in an ad hoc manner or according to proficiency (“the tuning guy”, “the capacity planner”, “the troubleshooter”.)
A few customers of mine once complained of a desktop diagnostic product that collected performance metrics independently. The trouble was that when a problem arose the “team” reacted in the same uncoordinated way as a youth soccer team. Without a plan they all rush to the ball and run around in a clump kicking until something pops loose. The trouble is when this same approach was used for diagnostic troubleshooting, 5-10 DBAs simultaneously connected to an instance already in distress and added 5-10 realtime performance monitoring connections. And the diagnostic tool became part of the problem instead of the solution. (Rather than debate the need for a more coordinated approach with the customers, the product was modified to lock out new connections after some limit.)
If the organization is large enough and has had enough bad experience with the ad hoc hero approach, then some sort of structure is applied to the DBA responsibility. Sometimes it goes by technology specialty, sometimes by business unit alignment, sometimes by simple geography. Everyone knows who is primary on any given instance, but that person often still resorts to using other DBA specialists on the team depending on the task or situation. One customer even had an automated scorecard by DBA that the DBA manager used to keep track of who was maintaining patch levels, keeping up with backups, and maintaining SLAs for the application users. Rather than worry about monitoring instances or databases, the DBA manager monitored DBAs and left them to their business as long as the scores stayed high. (Product idea?)
Finally, large organizations do all this and more by adding the dimension of DBA specialty. There are Application DBAs who focus on application performance; Operation DBAs who make sure the lights stay on and the data is always backed up; Development DBAs who serve as the buffer to poorly designed SQL applications from developers themselves. Engineering DBAs who do nothing but work on finding tools and best practices to standardize across all those other DBAs in the organization and make them more efficient. (By the way, it isn’t just marketing hype; database tools do increase the ratio of instances an individual DBA can handle well. There aren’t many DBAs out there with the luxury of time to maintain their own scripts for all tasks, but they still exist.)
If you stayed with me so far then you might recognize a similarity to the Capability Maturity Model used to describe organizations and software development processes. The paradox is that each level of “maturity” also adds complexity and those ad hoc DBA heroes in small shops can be more efficient than highly organized teams. But you simply can’t function in a large organization with a large team of freelancing DBA heroes, no matter how good they might be as individuals.
Regardless of where you find yourself on this pyramid, you probably recognize you are part of a team. You either have to work with developers, storage administrators, virtualization administrators, or even business customers to get your job done efficiently. The same tasks that those specialized teams do in larger organizations have to be done by someone somewhere, maybe not done well, but someone is filling those roles whether they are DBAs or not.
Lone ranger or not, all would fare better if they sought out ways to collaborate more efficiently with other stakeholders.
Now for a word from our sponsor:
One underused capability in Diagnostic Manager is Newsfeed. On the surface, this feature might appear to be a social media superficiality. But it really is built to enable collaboration across teams. The benefits include:
- Self-subscription to servers important to you or fellow team members activity
- Centralized way to communicate around performance problem resolutions
- Audit trail for handing of alerts and notifications
- History of incidents and resolutions for collective intelligence
The concept is simple; the implementation is unique. Instead of having a central administrator assigning which alerts go to which DBA (or developer or other IT stakeholder), each user selects what is important to them to watch. As the team addresses issues, then they add comments that are in turn distributed to the same interested parties. If you try it, it can be fun to follow a troubleshooting exercise in the historical feed and learn from past mistakes.
Tell us more about your experience on a DBA team, even if that is a team of one, by answering this brief survey. DBA Team Survey
