I have sat in too many meetings in Turkish banks and insurance companies where a data manager nodded along while a DBA explained why a regulatory report was three hours late. The manager did not understand what was being said. The DBA knew it. The auditor sitting across the table also knew it. That is not a technical problem. That is a leadership failure with a cost attached to it.
This post is about where that line should sit. Not every data manager needs to be a DBA — that is the wrong target. But there is a minimum technical floor below which you cannot evaluate the people you depend on, and in regulated finance that floor is higher than most managers admit.
What the Dependency Actually Costs You
When the BDDK or SPK comes asking why a transaction reconciliation report missed its window, the answer cannot be "the DBA said the database was slow." You will be asked:
- Which query stalled, and on what wait event?
- Was it a one-time spike or a recurring degradation?
- What was the execution plan before and after?
- Why was the fix not applied earlier?
If you are routing every one of these questions to the DBA team and waiting hours for an answer you cannot verify, your audit response time is structurally broken. I have seen institutions take four business days to produce a credible root cause for a single failed end-of-day batch. The regulator does not care that your org chart separates data management from database administration.
There is also a quieter cost: architectural decisions made by the wrong people. When a DBA tells you "we need to partition this table by month, not by branch," and you cannot reason about it, you either accept it or escalate it into a political fight. Neither is engineering.
What You Must Own
These are non-negotiable. If you manage data in a regulated environment and cannot do these, you are exposed.
Read an execution plan. Not write one — read one. You should be able to look at a plan and identify a full table scan on a 400-million-row transaction table, recognize a nested loop where a hash join belongs, and ask why an index is not being used. In Oracle, EXPLAIN PLAN and DBMS_XPLAN.DISPLAY_CURSOR are not DBA tools. They are management tools. When someone says "the query is slow," your first question should be "show me the plan," not "how long will it take to fix."
Interpret the top five wait events. db file sequential read, db file scattered read, log file sync, enq: TX - row lock contention, and library cache: mutex X cover most of what kills a finance workload. If your nightly policy renewal batch is stuck on log file sync, the answer is not more CPU. If it is stuck on row lock contention, the answer is not a faster disk. Knowing the difference is the difference between a useful conversation with infrastructure and a blank check.
Reason about tablespace pressure and growth. You should know which tablespaces hold your largest fact tables, what their growth rate is, and what happens when one fills up at 02:00 during a batch. I have watched a claims processing pipeline fail because nobody had looked at DBA_TABLESPACE_USAGE_METRICS in six months. The DBA was blamed. The data manager should have been.
Understand undo and redo behavior. When a long-running reconciliation query fails with ORA-01555, you need to know whether the answer is a larger undo tablespace, a shorter query, or a different isolation approach. This affects how you design ETL windows.
Know what AWR and ASH reports tell you. You do not need to generate them. You need to read them. When the DBA hands you an AWR report covering the problem window, you should be able to find the top SQL by elapsed time and ask intelligent questions about it.
What You Can Safely Delegate
This is where most managers either overreach or under-delegate. Both are expensive.
- RMAN backup configuration and recovery testing. Own the policy and the test schedule. Do not own the syntax.
- Data Guard setup and switchover procedures. Know the RPO and RTO. Let the DBA own the mechanics.
- Patch application and PSU planning. Approve the window, review the rollback plan, do not write the runbook.
- Storage layout, ASM disk group management, and redo log sizing. These are infrastructure decisions with database implications. Review them, do not design them.
- Parameter tuning beyond the obvious.
SGA_TARGETandPGA_AGGREGATE_TARGETyou should be aware of. The other 400 parameters are not your job.
How to Build the Floor Without Becoming a DBA
The fastest path I have seen work: pick three production incidents from the last six months. Sit with the DBA who resolved them and walk through the diagnosis end to end. Not the fix — the diagnosis. Ask to see the AWR report, the execution plans, the wait event analysis. Do this until you stop needing translation.
Then pick one query that is currently slow in your environment. Read its plan yourself. Form a hypothesis. Compare it to the DBA's. You will be wrong the first several times. That is the point.
The goal is not to take work away from your DBA team. The goal is to be a peer in technical conversations about your own data. In finance and insurance, where every minute of downtime has a regulatory and reputational cost, that peer status is not a nice-to-have. It is the job.