All jobs / Database administrator
Monitoring interview questions
Monitoring questions a Database administrator can be asked, from first job to senior. Open one to see the strongest answer and why it works.
You inherit a database with no monitoring. What do you watch first?
The strongest answer: Backup success and age, disk space and growth, replication health, connection count against the limit, and the slowest or blocked queries
Why it works: Exactly — the things that turn into data loss or outages if nobody is watching.
- Backups, disk, replication first.
- Connections against the limit.
- Slow and blocked queries.
- Up is not healthy.
Someone asks whether seventy per cent CPU on the database server is a problem. What do you need before you can answer?
The strongest answer: What it normally is at this hour on this day — a number is neither good nor bad without the usual pattern — and whether response times users feel have changed
Why it works: Right — a baseline turns a number into a signal, and the user-facing symptom decides whether it matters at all.
- A number needs a normal.
- Baseline by hour and by day.
- Ask what users are feeling.
- Diagnose before buying hardware.
The primary’s data volume alert fires at ninety-five percent and the growth chart is steep.
What do you do?
The strongest answer: Buy time first — free the fastest safe space, such as log archives already backed up — then find the cause of the growth, add space or fix it, and alert far earlier next time
Why it works: Exactly — stabilise safely, find the cause, then fix the alerting that let it get this far.
- Free safe space first.
- Find the growth cause.
- Never delete the only backup.
- Alert much earlier next time.
Connections to the instance jump from a steady eighty to the configured maximum, and the application starts timing out.
What do you look at?
The strongest answer: What the sessions are doing — if most wait behind one blocker or sit idle in a transaction, the count is a symptom; if all are working, it is real load or a growing pool
Why it works: Exactly — the count tells you there is a queue, and the session state tells you what the queue is waiting for.
- The count is a symptom.
- Look at what sessions wait on.
- Blocked and idle-in-transaction first.
- Raise limits only after diagnosing.
The database is “slow” in general. How do you find which queries to fix?
The strongest answer: Use the engine’s statement statistics or slow-query log to rank queries by total time and calls, not just the slowest single run, and fix the few at the top
Why it works: Exactly — aggregate cost finds the frequent medium query that hurts more than the rare slow one.
- Rank by total time and calls.
- The frequent query often beats the slow one.
- Fix the top few.
- Measure, do not guess.
The database server has been at a hundred per cent CPU for twenty minutes and the application is crawling.
What do you check, and in what order?
The strongest answer: First whether the database process is the one burning it — a backup or an agent can be — then the top queries by CPU time, then what changed: a plan, an index, a load
Why it works: Right — confirm the process, then the queries, then what changed; that order stops you tuning a query when a backup is the cause.
- Confirm which process burns CPU.
- Then the top queries by CPU.
- Then what changed: plans, indexes, data.
- Do not restart to diagnose.
Which database signals deserve a page at night rather than a morning ticket?
The strongest answer: Things that become data loss or a hard outage if left: backup failure, replication broken or lag past the RPO, disk about to fill, connection limit reached, and a blocking chain that is not clearing
Why it works: Exactly — page on impending loss or outage; ticket the rest.
- Page on data-loss risk.
- Page on impending outage.
- Ticket performance drift.
- Design decisions in daylight.
Queries that used to finish in milliseconds are slow, and the top waits are on storage.
How do you tell whether the storage is at fault or the database is asking far more of it?
The strongest answer: Read latency against throughput: high latency at low throughput points at the device or path, while latency that rose with a jump in reads points at a plan change or a lost index
Why it works: Exactly — latency against throughput is what separates a slower device from a database suddenly demanding much more of it.
- Read latency and throughput together.
- High latency, low throughput: the device.
- Latency plus more reads: the workload.
- Compare engine, host and array views.
How do you tell that an instance is short of memory rather than short of something else?
The strongest answer: Pages are evicted and re-read, so old cache hits go to storage; sorts and hashes spill to disk, memory grants queue, and the host may page — I read those together, not one ratio
Why it works: Right — eviction pressure, spills and queued grants together, because a single ratio can look healthy while the instance thrashes.
- Look for eviction and re-reads.
- Watch spills to disk.
- Watch queued memory grants.
- One ratio proves nothing.
Two senior DBAs carry all the on-call. How do you build a sustainable rota with the juniors?
The strongest answer: Shadow shifts first, runbooks good enough that a junior can act, a guaranteed senior escalation, alert clean-up so pages are rare and real, and a review after each shift — then rotate everyone
Why it works: Exactly — build the safety net, then widen the rota.
- Shadow before solo.
- Runbooks a junior can execute.
- Guaranteed escalation.
- Clean up alerts first.