What does it mean to be a SQL Server DBA

By:   |   Updated: 2014-07-17   |   Comments (12)   |   Related: More > Professional Development Career Planning


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


sql server categories

sql server webinars

subscribe to mssqltips

sql server tutorials

sql server white papers

next tip



About the author
MSSQLTips author Jeremy Kadlec Jeremy Kadlec is a Co-Founder, Editor and Author at MSSQLTips.com with more than 300 contributions. He is also the CTO @ Edgewood Solutions and a six-time SQL Server MVP. Jeremy brings 20+ years of SQL Server DBA and Developer experience to the community after earning a bachelor's degree from SSU and master's from UMBC.

This author pledges the content of this article is based on professional experience and not AI generated.

View all my tips


Article Last Updated: 2014-07-17

Comments For This Article




Friday, December 14, 2018 - 10:27:53 AM - jmoden Back To Top (78497)

Great article.  Thanks for taking the time to write it.

I think, however, there is an attribute of really successful DBAs that needs to be mentioned and it's spread out across all 5 categories mentioned in the article and could possibly be listed as a 6th category.  The trait can be summarized with the category of "Mentor".

As a "Protector", you need to protect the Developers.  What I mean by that is that educating them will help them do their jobs both better (help them do it right the first time, which eliminates a ton of rework and possible embarassment and making them much more valuable to the company) and faster (they won't have to do as much research to do it right the first time... they'll just know how to do it).

As a "Detective" and "Scientist", you establish a rapor with the Developers where you're the first person they'll ask for database help on difficult problems rather than the last.

As an "Advocate", you've setup procedures for code reviews and deployments for the Developers to follow.  If something comes up where a Developer is being blamed for something, you can be their advocate that they did things the right way and that whatever happened isn't actually their fault.  When I first start doing this at new companies I may work for, you'll run into some pretty serious resistance.  I tell the Developers that the rules aren't to make their lives difficult.  It's so that I can protect them and I can't protect them if they insist on being a Cowboy on the open range.  That doesn't mean that I fetter their innovaiton but help them inovate in a safe manner.  If managment calls one of them out on the carpet for something, I'm right there to be an advocate for the Developer because I actually do know how they Developed something because I've done the peer reviews and worked with them on the code.  In fact, I sit with the Developers so that I can hear what they're going through especially when a Manager or some user shows up to discuss something and have been known to jump in on a conversation if I'm able to help especially in the face of unreasonable requests.  For example, we document everything we do.  If someone wants something done right now and the Developer is losing the battle in getting the user to open a ticket, that's when I'll jump in about the docuement flow of requests and how things must be done to be both safe and auditable.

And, yes, having your "ear on the rail" as a "Conduit" can really help the Developers because it helps you prepare for what's coming so that you can anticipate their database coding needs and, frequently, say something like "I heard that you've been assigned such-and-such a task.  You're going to need to be able to do such-and-such.  I've done that in the past and here's an article to read (or actually code I've developed) that will make your life a bit easier".

Heh... This reminds me of the original "Star Wars" where Obi-wan says "Use the Force, Luke!"  Truly successful DBAs are that benifical force for the Developers.  "Protect and Serve" and those two verbs are not mutually exclusive.

 

Friday, January 20, 2017 - 1:49:21 PM - Randy Back To Top (45447)

 I see nothing here about backup/restore.  While I do everything mentioned above as a SQL Server DBA, I believe the most important thing I do is protect the organization's data.  Given all the things that can trash a database, an organization needs to have faith that the DBA will be able to bring them back from a disaster.  Servers can be rebuilt, applications reinstalled, but if the data is gone... 

You as the DBA must know you have procedures in place and confidence in them and yourself that you can bring a dead database back.  Otherwise, what good are you?  Nobody will care how well you did anything else if the database is gone.  That's what it means to be a DBA.  And you have to do all the other stuff too.


 

Monday, July 21, 2014 - 11:25:45 AM - Jeremy Kadlec Back To Top (32804)

FrankQ,

Thank you for the post and feedback.  The "Scientist" and "Data Scientist" references in the section you mentioned are not intended to be a literal job titles, but rather functional roles.  As I mentioned, "DBAs have been applying some basic scientific principles to managing and building code for decades."  Items such as testing, troubleshooting and correction. 

HTH.

Thank you,
Jeremy Kadlec
MSSQLTips.com Co-Leader

Monday, July 21, 2014 - 11:18:57 AM - Jeremy Kadlec Back To Top (32803)

Thulasi,

Agreed and thank you so much for the post.

Thank you,
Jeremy Kadlec
MSSQLTips.com Co-Leader

Sunday, July 20, 2014 - 11:15:14 PM - FrankQ Back To Top (32798)

Jeremy,

Data Scientist has nothing to do with DBA. Data Scientist applies statistics to the available data. So knowledge discovery, data mining, and so on. In terms of SQL Server, Data Scientist works with tools such as SSAS and HDInsight.

Friday, July 18, 2014 - 5:44:52 AM - Thulasi Back To Top (32767)

Absolutely agree with you.. DBA's also play key role while planning for High Availability or DR Solution  for any business application. Probably DBA's will have good idea to suggest a solution for their own platform.

Thursday, July 17, 2014 - 12:11:25 PM - Jeremy Kadlec Back To Top (32759)

Tak,

Thanks so much and congrats!

Thank you,
Jeremy Kadlec
MSSQLTips.com Co-Leader

Thursday, July 17, 2014 - 12:10:43 PM - Jeremy Kadlec Back To Top (32758)

David,

I agree as well.  The more you know the more you are worth.  DBAs are generally in the center of a great deal of technology and business processes.

Thank you,
Jeremy Kadlec
MSSQLTips.com Co-Leader

Thursday, July 17, 2014 - 12:09:31 PM - Jeremy Kadlec Back To Top (32757)

Ron,

Thanks so much for the feedback.  I agree.  You really need to know SQL Server.

Thank you,
Jeremy Kadlec
MSSQLTips.com Co-Leader

Thursday, July 17, 2014 - 11:26:55 AM - Tak Back To Top (32756)

Great write up on DBA traits! Have experienced most of them.

 

@David Thomas .. Totally agree with his comments!

 

Thursday, July 17, 2014 - 9:34:46 AM - David Thomas Back To Top (32755)

DBA = Database Administrator.    No it stands for Do Bout Anything, Anytime.

The skill you will need is the one to embrace all aspects of I.T.     You will be expected to be to know something about everything and everything about database.

After tenure you have many of the skills of the architect

 

Thursday, July 17, 2014 - 8:17:28 AM - Ron Back To Top (32751)

I agree with all of this stuff.

You also have to KNOW SQL Server.














get free sql tips
agree to terms