Onboarding a New DBA

A new DBA can connect to a server long before they understand what depends on it. Onboarding a new DBA should build safe access, a map of the estate, and practiced recovery steps before independent production changes.

Give Access in Stages When Onboarding a New DBA

Start with read-only access to monitoring, metadata, and documentation. Add change rights only when the DBA has learned the environment and the approval process. Separate production and test credentials clearly. Document how multifactor access, jump hosts, and emergency accounts work. Avoid sharing a team login because it hides who performed an action.

I test each access path with the new person present. A role listed in an access request does not prove it works from the actual workstation. Which task should the person be able to perform today? Grant for that task and review the result. This is faster than discovering a missing restore permission during an incident.

Build a Map of the Estate

Show instances, databases, applications, owners, backup destinations, high availability, and critical schedules. Mark systems that are retired or in migration. A diagram without named owners becomes stale quickly. Keep a source of truth and explain how it is updated after a deployment.

I ask the new DBA to find one application from a user report and trace it to the database and support contact. That exercise finds gaps in the map. It also teaches why two similar instance names can have very different risk. A query to identify the connected server is a useful habit from day one.

SELECT @@SERVERNAME AS connected_server,
       DB_NAME() AS current_database,
       SUSER_SNAME() AS current_login;

Walk Through Runbooks

Read the backup, restore, failover, patching, and incident runbooks together. Point out preconditions and stop points. Then have the new DBA follow one runbook on a disposable environment without hints. If a step requires unwritten knowledge, improve the document. A runbook is a tool, not a ceremonial folder.

I focus on recovery first. The person should know where backups live, how keys are protected, and how a restore is tested. They do not need to memorize every command. They need to recognize when a command is dangerous and where to verify the next step.

Observe a Weekly Routine

Let the new DBA shadow a weekly review of backups, job failures, capacity, integrity, and performance changes. Explain why each check exists and what would make it urgent. A green dashboard can contain a missing database if the inventory is incomplete. Show how the team confirms coverage.

This query lists user databases and recovery models. It is a first step, not a backup report. Ask the new DBA to compare it with the monitored database list. I like that exercise because it turns a catalog query into a question about operational completeness.

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

Practice One Restore While Onboarding a New DBA

Schedule a restore of a recent backup into a safe environment. Include file selection, the required log sequence, keys, integrity checks, and an application smoke test. Have the new DBA write down where the runbook was unclear. The drill should finish with a recovery point and duration measured on that environment, not an assumed promise.

I review the plan before any restore command runs. Which database will be overwritten? Which file paths are used? A person who asks those questions is learning the right habit. The first restore should be supervised, then repeated independently after the runbook is corrected.

Give a Small Supervised Change

Choose a low-risk change with a clear rollback, such as adding a monitoring check in test. Ask for a written plan: target, reason, evidence, script, validation, and rollback. Review the plan together, execute it in the approved window, and compare expected with actual output. This teaches the team’s change process through work.

I do not measure onboarding a new DBA by how quickly someone receives sysadmin. I measure whether the new DBA can explain the system and stop when evidence conflicts with the plan. A small safe change reveals more about that than a week of passive reading.

Set First-Month Outcomes for Onboarding a New DBA

By the end of the first month, the new DBA should find a database owner and read backup health without help. They should also run a test restore, follow an incident runbook, and explain one supervised change. Adjust timing to the environment and the person’s experience. Keep a named mentor and regular questions channel.

What question did the new DBA ask that exposed a missing document? Fix it. I treat onboarding a new DBA as a test of the team’s operational memory. If every answer depends on one person, the work is not finished even when the new account can connect.

A new DBA should have a safe map before receiving broad permissions. Provide an inventory of instances, applications, owners, backup locations, restore targets and maintenance schedules. Explain which alerts require immediate action and which are informational. I start with read-only observation and a supervised restore rehearsal so the person can learn the estate without guessing during an incident.

The first month should include a small real task with a clear review path. Updating a runbook, validating one backup chain or tracing one slow query builds familiarity and produces evidence. Pair the new DBA with someone who can explain local exceptions, including settings that appear unusual but are deliberate. A checklist is useful only if it names an owner and a way to confirm each item.

Access should grow with demonstrated understanding and role need. Handing over sysadmin on day one is not an onboarding plan. The goal is a colleague who can describe the system, ask the right question and follow a recovery path without relying on folklore.

Include a tour of the existing mistakes, not just the standard build. Known exceptions, aging dependencies and recurring alerts explain why the estate looks the way it does. I make the new DBA write down questions during that tour and then use those questions to improve the runbook. Onboarding is a practical test of documentation quality. If every page requires an interpreter, the pages need work.

Related reading on this blog: What AI Thinks a DBA Does All Day and Balancing Performance, Security, and Scalability as a DBA.

Onboarding is not granting sysadmin, it is building safe judgment about a specific estate.

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