What a DBA Actually Does All Day

The useful answer to what a DBA does is not a list of buttons in Management Studio. The job is to keep data available, recoverable, protected, and usable as the business changes.

Start With Services That Matter

A DBA needs to know which applications depend on each database and who owns them. Availability expectations differ between a payment service and an occasional internal report. That context determines which alarm deserves immediate attention.

The day often starts by reviewing overnight outcomes and unresolved incidents. A healthy server icon is not enough if the scheduled load failed. The real question is whether the business process can do its work.

SELECT name, state_desc, recovery_model_desc,
       log_reuse_wait_desc
FROM sys.databases
WHERE database_id > 4
ORDER BY name;

This small inventory provides a starting view of database state. It does not measure the whole service or prove that applications can connect. Good operational checks combine engine evidence with the user’s actual task.

Handle Incidents Without Making Them Larger

When something fails, the DBA narrows the cause and helps restore service. That can mean investigating blocking, exhausted space, a failed deployment, or an unavailable dependency. Not every incident begins inside the engine.

SELECT session_id, status, command, wait_type,
       blocking_session_id, cpu_time, total_elapsed_time
FROM sys.dm_exec_requests
WHERE session_id <> @@SPID
ORDER BY total_elapsed_time DESC;

The work includes explaining impact and uncertainty to other teams. A useful update states what is known and what the next check will establish. Confident guesses do not become evidence through repetition.

After recovery, the DBA helps identify what would prevent a repeat. An incident that returns every week is a recurring engineering problem. It should not become a permanent appointment in the calendar.

Make Recovery a Practiced Capability

Backups need schedules, retention, accessible media, and restore tests. Someone must check that the required recovery sequence exists and can be used. That responsibility continues even when a platform automates backup creation.

SELECT d.name,
       MAX(CASE WHEN b.type = 'D' THEN b.backup_finish_date END) AS last_full,
       MAX(CASE WHEN b.type = 'I' THEN b.backup_finish_date END) AS last_differential,
       MAX(CASE WHEN b.type = 'L' THEN b.backup_finish_date END) AS last_log
FROM sys.databases AS d
LEFT JOIN msdb.dbo.backupset AS b ON b.database_name = d.name
WHERE d.database_id > 4 AND d.name <> N'tempdb'
GROUP BY d.name
ORDER BY d.name;

This history is local to the instance and can be retained or removed independently of backup files. Availability-group backups may have run elsewhere. Interpret missing entries with that context instead of immediately declaring a missed backup.

A good week includes progress on recovery evidence before an emergency demands it. Record what was restored, where, and how usability was checked. Recovery time is something to test, not something to wish into a service agreement.

Spend Time on Prevention

Prevention includes capacity planning, patch evaluation, access reviews, and performance baselines. These tasks rarely create dramatic screenshots. They reduce the number of dramatic calls.

SELECT DB_NAME(database_id) AS database_name,
       name, type_desc, size * 8.0 / 1024 AS size_mb,
       growth, is_percent_growth
FROM sys.master_files
ORDER BY database_id, file_id;

A current file-size snapshot becomes more useful when compared with earlier observations. Growth trends help plan capacity before space becomes urgent. Pair the numbers with workload changes rather than projecting a straight line forever.

Access reviews also require business context. An account can be technically valid and no longer needed. The DBA works with owners to keep permissions aligned with current responsibilities.

Help Projects Make Better Data Decisions

Project work can include schema design, migrations, new indexes, reporting changes, and deployment reviews. The DBA asks how those changes affect concurrency, recovery, and ongoing support. In some teams, developers share much of this responsibility.

The useful contribution is not simply saying no to every change. It is making tradeoffs visible and testing the important assumptions. A design that is elegant in development still needs a workable production life.

Documentation belongs here too. Record dependencies, ownership, and recovery expectations while the project team still remembers them. Waiting until handover turns simple questions into archaeology.

Automate Repetition and Keep Judgment

Automate reliable checks, scheduled maintenance, and routine evidence collection. Give each automation clear failure reporting and an owner. A silent script can fail more consistently than a person.

Keep decisions that require context visible to people. An alert should explain the condition and the expected response, not merely announce a threshold. Review noisy checks so attention remains available for meaningful failures.

A good week is not measured by the number of emergencies survived. It includes fewer surprises, better recovery evidence, and progress on planned improvements. The most valuable work may be the outage that never becomes necessary.

Database administration is not waiting for a failure, it is making dependable data a daily habit.

This post was rewritten from scratch in September 2026. The original, published on 2010-05-18, was a short announcement about something that no longer exists. The address is the same, the subject is now something worth keeping.

Published by Pinal Dave on SQLAuthority. More of my work at pinaldave.com.