6

I acknowledge that everyone's experience and abilities are different. Having said that, I want to avoid setting expectations too high (or too low) for a DBA that through actions; appears to be an 'administrator'.

Given:

  • I am a developer that is deep diving into SQL Server trouble shooting and performance issues. At night I'm watching Brent Ozar videos with a bucket of popcorn.
  • A company with several divisions, this division having around 100ish team members
  • Many customers with databases having millions of rows with ETL
  • A small DBA team that is stretched to handle these same customers. Handle HAG issues, backup, restores, create new deployments for new or upgrading customers.

I am NOT attempting to justify my own opinion. I wish to adjust either my opinion or others in the company.

Question:

Given the above, should expectations be that a DBA is simply an 'administrator'? Is this something you've typically seen?


I went into this soap opera (see my other recent questions) with the expectation that a DBA is 'expected' to deep dive. I have come to believe that I have misunderstood and I am leaning towards a DBA - being an 'administrator'.

I welcome others' experiences and perhaps advice on refining this question.

2
  • Hi D-K, what do you mean by HAG in Handle HAG issues[...]? – TT. Apr 30 at 10:44
  • 1
    @TT. guess High Availability Groups – Aleksey Vitsko Apr 30 at 17:14
5

Titles are just that, nothing more than a set of words, and the relevancy of their meaning are dependent on how you define that meaning within the context of your domain. In this case that domain is your company, so you guys should define the DBA role to fit the needs of the business (realistically under the umbrella of what a DBA can do).

DBA is one of those kinds of roles that I've found to evolve as a many hats or crossover type of position. The reasoning being is it's a career heavily populated by a mix of people who either were Software Developers, System Administrators, or neither, in a past life.

As someone who went from Software Developer to resident DBA to actual DBA at another company and back to a quasi-Software Developer / DBA now, I got to experience most of the database development and performance tuning side of being a DBA as opposed to server and database management - though I have and still do manage some of those aspects as well. This was because of my prior experience as a developer and because the companies I worked for needed someone who could write code but also help optimize performance in the database layer both from an architectural standpoint and a query tuning one.

So in summary, there is a rainbow of DBA roles out there between ones who essentially just administrate database systems and get their hands dirty under the hood of the servers themselves, others who purely do database design and performance tuning, and others who have a mix of actual software development (even outside the database layer) responsibilities and do performance tuning and database management.

3
  • Thanks J.D. I agree. However, I need to start somewhere and set some expectations with working within my company. Ultimately, I'm determining whether it makes sense to argue within the company that I should be given the keys to the castle to fill the role of the database developer (brentozar.com/archive/2018/06/…) and that our existing DBAs are indeed doing the job expected of them. – D-K Apr 29 at 19:38
  • 1
    @D-K Right, I gotcha. I recall your recent posts. In that regard, the best advise I can offer you is to continue self-learning database development and performance tuning and then you should be able to eventually make a realistic case for yourself that you fall in the quasi-developer side of a DBA. I'd recommend after you're confident in your knowledge that you should present your argument from a positive perspective of that you find database development and performance tuning interesting and you feel that you can optimize everyone's workloads (the developers side and the DBAs side) by... – J.D. Apr 29 at 20:20
  • ...having a little more access to the database layer, so you can be self sufficient and can help take some work off the DBAs plates. Interestingly enough, I've never worked anywhere where the developers didn't have a level of access to be self sufficient in the database (in DEV at least) and the DBAs were available for assistance with building bridges, not putting up walls lol. – J.D. Apr 29 at 20:21
4

I think that the figure of the DBA should be considered primarily as an administrator of the instance and responsible for its proper functioning, data storage, efficiency and availability of databases, but also for verifying the proper execution of procedures and processes in order to ensure a balanced use of resources.

In my experience it must be seen by programmers as an ally that must be consulted and involved from the earliest stages of the project. His point of view is valuable and different from that of a programmer. A programmer has his application at heart, a dba the entire application ecosystem that relies on the instance.

Their relationship must be synergistic, not conflictual.

1
  • 1
    If the team ran into a problem that wasn't specific to any one product but more of a perfect storm of queries hitting together and causing issues. Is that same DBA the deep dive or would you have software developers with core database design experience digging into the issue? I have been speaking with a previous DBA to the company and he gave me an eye opener - he said he considered himself the last database 'developer'. That right there started to change my expectations. – D-K Apr 29 at 17:19
3

If you are faced with shallow problems, you'll not need to do any deep dives.

If you are faced with complex problems but are not experienced enough then you'll not get to do deep dives. Others will dominate those as complex problems are sparse and smart people look for them.

If you are the only DBA and the others are not experienced enough (they will delegate work to databases without thinking what they are doing), you'll have to do deep dives. This is the case in an typical web development environment. You should do such deep dives, even if someone says you that you should, or shouldn't.

Such complex computing and development environments have many stakeholders in place. If your organization reached some maturity levels, then you'll have enterprise developers/architects as well as database developers/architects in place. In collaborative self critical environment enterprise developers are aware that their art to solve problems is useful but have blind spots. Data developers do useful stuff have blind spots too and hope that those blind spots are not the same as for enterprise developers. Deep diving will help push frontiers further.

2
  • What do you mean by "they will delegate work to databases without thinking what they are doing"? – Bergi Apr 30 at 11:13
  • 1
    @Bergi probably meant that people try to make a tool do something it wasn't meant to do. They don't really understand the tool (the database) and lump more and more into its responsibilities with little true understanding of the consequences. – D-K Apr 30 at 18:53
2

Answers originally left as comments:

As a DBA, I do a lot more than administer. I make sure things perform better-than-well and ensure developers are not trying to skirt the rules involved when interacting with the systems. My job is to protect the data from external and internal threats, be they malevolent or otherwise. I teach people about the system. I answer new questions from the business. Those answers — hopefully — result in better decisions. “Anyone” can administer a database, but not everyone can manage one. - matigo


It will vary company by company. Brent Ozar has a quick graphic on this but bigger/older the company, the more slim the responsibilities in my experience. Smaller/start-ups will lean more on a hybrid data engineer or site reliability engineers for classical DBA duties + automation + tuning + code writing. - lowlydba-john-m

1

I went into this soap opera (see my other recent questions) with the expectation that a DBA is 'expected' to deep dive. I have come to believe that I have misunderstood and I am leaning towards a DBA - being an 'administrator'

DBA is not necessarily an 'administrator'

What you are reference to is a Production DBA

But there are also Development DBA who focus on performance tuning and writing queries.
Here you can read more (this is in addition to lowlydba's link, check that out as well)

https://www.brentozar.com/sql/picking-a-dba-career-path/

Whether or not DBAs at your company should 'deep dive' into runtime query performance issues, I think it depends from answers on questions "what they were hired for ?" and "what their job description is ?"

If particular person's job description does not strictly say Production DBA (and the only functions they expected to perform is backups, HAG, keep the lights on servers, automate, etc.) then 'deep dive' is not only expected, but you have the right to demand it. Good DBA won't be waiting for someone to demand something, but rather fixing problems proactively and beforehand, though

1
  • 1
    While a part of me wants to agree with your last sentence - another part of me recognizes that a DBA also has a razor edge to dance upon and this is greatly influenced by the skill of the DBA. A DBA that is sharp and on her game, can do what you suggest. Then there are other DBAs that can certainly get the job done - but the risk of breaking something is there. They have been burned before and only respond to fires. That later situation is where I find myself standing in. – D-K Apr 30 at 19:03

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.