You often read on social networks that a DBA’s job is to optimize databases, among other things. I think that’s a misinterpretation of the – important – role of a DBA. Why? I’m happy to share my opinion on the role a DBA has to play in a company and why tuning is not one of them! I was working as a DBA in multiple Enterprise Companies for more than a decade.

A story from my life as a DBA

In 2007, I got my first project as a DBA in a large bank in Germany. I had previously successfully carried out database development for customers and was therefore happy to be taken on for the DBA project. My knowledge of T-SQL, query optimization and analysis of performance bottlenecks were to expand the team of 3 existing DBAs.

The most important databases were hosted on physical servers. A total of 8 instances were hosted per physical server. One day, ALL instances of a server unexpectedly came to a standstill and nobody knew why. I was lucky and was able to locate the affected instance relatively quickly. The cause was a big query that ran in parallel (consuming all processors) for a long time and blocked all processors.

Please no discussions about the wrong configuration of the instances. Today I know better and in my defense I would like to point out that the servers had already been in use with this configuration for several months!

The first reaction of my team lead was the limitation to one core (MAXDOP 1) to get all other instances working again! In my new role, I wanted to show what I was capable of and took on the problem with the arrogant belief that I could do it better. When I examined the problematic query, I realized that the problematic query could be improved by an index and, confident in my abilities, I implemented the index. Problem solved! Great, I was starting to enjoy the role of a DBA.

The application owner then wrote me an email thanking me for my efforts and saying that the new performance of the query had been positively noted in the business. My team manager was dutifully added to the email in cc. Great – I could already see an increase in my hourly rate coming my way; things turned out differently than I expected.

My team manager came to me within a few minutes and thanked me with the following words:

• Thank you for reacting so quickly and solving the problem.
• If you do that again, you’re fired.

To understand why he reacted that way, you have to understand the role of a DBA in an enterprise environment. A bank is not a kiosk and one of the most important principles is traceability in a production environment. With my activities, I broke EVERY rule there was for an operational team!

Role/Responsibility of a DBA

To make it clear! From my understanding the technical and business roles of a Database Administrator (DBA) in an enterprise company like a bank, where a separation of duty (SoD) rule is enforced, are distinct and governed by regulatory and organizational policies to mitigate risks such as unauthorized access, data breaches, or fraud.

Under SoD, the technical responsibilities are carefully scoped to ensure that the DBA focuses on operational and administrative tasks without overlapping into areas like application development or auditing.

Database Management and Maintenance

• Install, configure, and upgrade database software.
• Monitor database performance and ensure high availability and disaster recovery solutions.
• Apply patches and updates as part of maintenance routines.
• Ensure database backup and restoration capabilities are functional.
• Access Control and Security Implementation

Incident Management

• Respond to technical incidents related to the database (e.g., outages or corruption).
• Collaborate with IT security teams during a security breach affecting the database.

Compliance Management

Implement technical controls to support compliance requirements (e.g., GDPR, PCI DSS, SOX).

Restrictions under SoD

• DBAs should not be involved in developing database code or directly modifying database code.
  INDEXING is DEVELOPMENT!
• DBAs should not have unlimited access to business-critical data unless explicitly authorized (e.g., for troubleshooting or maintenance).

Business Role of the Database Administrator

The business role is centered around ensuring that the database environment aligns with the organization’s objectives, supports strategic initiatives, and adheres to compliance requirements.

Strategic Support

• Collaborate with business units to understand data requirements for reporting, analytics, and operational workflows.
• Assist in planning database growth and scalability to meet long-term business objectives.

Compliance and Audit Facilitation

• Provide database audit logs and activity reports for internal and external audits.
• Act as a liaison between IT teams and auditors, ensuring technical implementation meets regulatory standards.

Risk Mitigation

• Identify and mitigate risks related to database downtime, data corruption, or unauthorized access.
• Maintain segregation of duties to prevent potential conflicts of interest or fraud.

Collaboration with Other Roles

• Work closely with application developers, security teams, and data owners without overstepping boundaries set by the SoD rule.
• Ensure clear communication with the business about database capabilities and limitations.

Governance and Policy Adherence

• Adhere to organizational policies regarding data governance and ethical handling of information.
• Ensure database practices align with overarching IT governance frameworks like COBIT or ITIL.

Restrictions under SoD:

• DBAs should not independently approve or validate changes impacting financial or critical systems.
• DBAs must avoid any direct involvement in defining business rules or decisions, ensuring they act as enablers rather than decision-makers.

Back to my problem – what did I do wrong?

My advantage was that my team manager was an empathetic colleague who preferred to explain things calmly rather than immediately hitting out with a sledgehammer. He explained to me the problems that could arise from my activity and the consequences that could result from them:

• Implementing a solution in a production system without an incident ticket
• ​​Taking on a task that I could not estimate because I had no idea what the application does and what implications the index I set could trigger.
• „Cover my ass“ – an important lesson. If the application were to perform poorly in another place (and had NOTHING to do with my adjustment), a product owner would first point the finger at me and say: Uwe did something without informing us beforehand
• What would have happened if it had been vendor software? The vendor could have refused any further support.

The lessons I learned from it

A DBA can advise a development team at any time and be a great help in optimizing an application. However, a DBA definitely does not have the task of proactively looking for performance problems – rather, he can/should reactively draw the attention of the development team/manufacturer to the problems found through a root cause analysis.
With this knowledge, the team can – no, the team MUST – make its own decisions about how to deal with the findings.
A DBA has to concentrate on the actual work. This work mainly consists of providing a reliable, maintained and secure environment for the customer’s databases.
A DBA is available to advise the business on the selection of the database system and its configuration dimension. But the crucial thing is that it is ADVISORY and never PROACTIVE performance tuning.

Thank you for reading!