Problem
I am aspiring to become a SQL Server DBA. I have seen numerous sets of information related to SQL Server tests, conferences, user groups, your tips and more, but what does it really mean to be a SQL Server DBA? What should I really aspire to become as a SQL Server DBA?
Solution
In many respects, a SQL Server DBA wears numerous hats and responsibilities may vary from one organization to the next. Although the implementation, technology, responsibilities, etc. may vary, there are a handful of common character traits that I have observed in a number of SQL Server DBAs that I respect and admire. I would like to share these with you because I believe they can help you with your career.
Protector
The first thought that probably comes to mind with the word “Protector” is security. With numerous data breaches, SQL Server DBAs are responsible for protecting the SQL Server environment and data from a security perspective. Of course. However, I think the protection offered by most SQL Server DBAs is well beyond security.
Protection includes the following:
- Prevention – Anticipating and preventing problems before they occur. This could be related to a poorly performing query or putting the brakes on a service pack installation because you know one group has not had sufficient time to test due to tight deadlines for another project.
- Minimization – Minimizing costs through automation, low head count and extending the life of the SQL Server platform.
- Compliance – In many respects there are shades of gray when it comes to complying with legal standards in particular industries. DBAs generally take the time to understand the need, how it applies to their organization and then find a solution that can work for the application, company, etc. ultimately with the intention to protect the company from a legal issue.
- Correction – I have seen numerous DBAs over the years proactively address issues. I have seen numerous examples where a DBA will fix issues they are aware of rather than ignoring them and letting them snow ball into an issue directly impacting the business. They were not asked to address the issues and they did not cover anything up, they fixed an issue, communicated it and moved on to the next item.
These are simple examples I have seen over the years where DBAs have protected the business from a negative experience with the application, users and business. By knowing the dependencies of your team, projects, code, etc. DBAs are able to save time and money to directly help the bottom line.
Detective
I am sure everyone has been in this situation: A problem occurs, regardless if it’s an upgrade, performance, design, HA\DR, support, etc. issue, then the finger pointing and politics start. Rather than finding the root cause of the issue people start shooting from the hip with the issue and answer rather than having the data and analysis to determine the root cause of the issue.
SQL Server DBAs acting as a detective include:
- Data – Depending on the issue, a variety of data can help troubleshoot an issue. I have seen numerous SQL Server DBAs proactively capture data about the environment either with home grown processes or using a third party product. Often, this data becomes invaluable to understand changes to an environment when an issue is occurring.
- Analysis – Without data, analysis is tough, but with data related to an issue you have the ability to compare data when there were and were not issues.
- Timeliness – When there is an issue, working fast is imperative. I have seen numerous SQL Server DBAs with the innate ability to break down the problem, build a timeline of events, put the pieces of the puzzle together and more.
Build your repository of data for a clear picture of your environment and be ready to be a detective when you need to find the root cause of the issue.
Scientist
The term “Data Scientist” has become popular recently, but to me DBAs have been applying some basic scientific principles to managing and building code for decades. I have seen DBAs serve as Scientists in the following situations:
- Testing – Just because you expect a piece of code to outperform any other option, does not mean it will. Testing your hypothesis is imperative to validating the code will work and not negatively impact other portions of the application.
- Troubleshooting – Looking at the issue sometimes you have a hunch about the root cause of the issue. This can help arrive at the solution faster, but it is also imperative to have an open mind and not let any sort of bias obstruct the solution.
- Correction – Often times there are numerous ways to correct a problem. Selecting the best solution for the problem is not just about blindly implementing an option that is considered a best practice, but truly understanding the best solution under the circumstances.
As you work through your day to day tasks or surprises as a DBA, be sure to apply some simple principles to guide your decision making process.
Advocate
In most organizations the DBAs are towards the bottom of the ladder, but I have seen numerous DBAs serve as advocates for either changing particular processes, correcting issues or adopting a better solution to benefit the organization. I have seen situations when a need is not being met and DBAs have spoke up to make sure a particular issue gets the attention it needs. SQL Server DBA Advocacy includes:
- Change – Depending on the circumstances, change can be good or bad. I have seen SQL Server DBAs understand how changes can impact the overall platform from users to storage. Understanding the changes and looking across the landscape of the application are imperative as you gain experience as a SQL Server DBA.
- Consistency – Being “consistent for consistency’s sake” can improve automation and management, but knowing when to advocate for change, to improve the environment can really show your expertise.
- Canary in a Coal Mine – Knowing when to raise an issue is tough, but often a characteristic of numerous successful DBAs.
Understanding the impact of fixing issues, changing how things have always been or being considered a source for guidance all come with years of experience.
Conduit
DBAs in many organizations are in the middle of numerous groups and sometimes have the ability to see across issues for troubleshooting as well as recognizing the cause and effect of a particular change. With this vantage point, be sure to help the organization understand the situation as needs arise and communicate among the groups in order to progress in a cohesive manner. SQL Server DBAs as Conduits include:
- Communication – Communicate your data, findings and analysis to correct and prevent issues.
- Connect the dots – With your vantage point in the organization, you should have the ability to see the cause and effect with changes and communicate those findings in a constructive manner.
As SQL Server DBAs, with your vantage point in the technology landscape communicate your findings and help the organization move forward.
Your Opinion Counts
Do you agree or not? Are SQL Server DBAs Protectors, Detectives, Scientists, Advocates and Conduits?
Do you see other common character traits for SQL Server DBAs that are not included in this tip? Well – I want to know and I want to hear from the community. Post them in tip comments below.
Next Steps
- Consider these character traits as a “SQL Server DBA Yard Stick” and see how you measure up. Think about opportunities for you to improve your service to your company and grow your career.
- Check out all of the MSSQLTips.com Professional Development tips. Here are some of my favorites:
- Check out all of my tips on the SQL Server Platform.
