Should a database 'administrator' have the ability to deep dive into runtime query performance issues?

Question

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.

Answer 1

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.

Answer 2

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.

Answer 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.

Answer 4

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

Answer 5

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