What a Junior DBA Should Learn First

A junior DBA needs a dependable learning order more than a huge collection of scripts. Start with protecting data, understanding access, and recognizing what the server is doing.

Learn to Find the Right Server

Before learning a powerful command, learn to prove where it will run. Check the instance, database, login, and version at the start of a session. Similar connection names are not a reliable safety mechanism.

SELECT @@SERVERNAME AS server_name, DB_NAME() AS database_name,
       ORIGINAL_LOGIN() AS original_login,
       SERVERPROPERTY('ProductVersion') AS product_version,
       SERVERPROPERTY('Edition') AS edition;

Practice in a separate learning environment with synthetic data. Save scripts with a short purpose and their expected scope. A script named final2.sql is a future support request waiting patiently.

Learn the difference between observing state and changing it. Reading a DMV and changing a database option deserve different levels of review. Build that distinction before collecting shortcuts.

Make Restore Practice the First Real Project

A backup is useful because it supports recovery. Learn full, differential, and transaction log backups in that order, then restore a compatible sequence. Understand the recovery model before promising point-in-time recovery.

SELECT name, recovery_model_desc, state_desc,
       log_reuse_wait_desc
FROM sys.databases
WHERE database_id > 4;
SELECT TOP (20) database_name, type,
       backup_start_date, backup_finish_date
FROM msdb.dbo.backupset
ORDER BY backup_finish_date DESC;

Use a disposable database and restore it under a different name in the lab. Work through file relocation, NORECOVERY, and final recovery with the documented syntax. Keep the original lab database available while learning.

Write down which backup files were needed and how you established that the restored data was usable. VERIFYONLY is helpful, but it does not replace an actual restore. Recovery confidence comes from completing the sequence.

Understand Who Can Do What

Learn logins, database users, roles, and permissions as separate concepts. A login connects to the instance, while database access involves a mapped or contained principal. The details matter when a restore moves a database elsewhere.

SELECT USER_NAME() AS current_database_user;
SELECT permission_name
FROM sys.fn_my_permissions(NULL, 'DATABASE')
ORDER BY permission_name;
SELECT r.name AS role_name, m.name AS member_name
FROM sys.database_role_members AS rm
JOIN sys.database_principals AS r
  ON r.principal_id = rm.role_principal_id
JOIN sys.database_principals AS m
  ON m.principal_id = rm.member_principal_id;

Do not solve every access problem with db_owner or sysadmin. Reproduce the required operation and identify the missing permission. Test both the action that should succeed and an action that should remain unavailable.

Catalog visibility also depends on permissions. An empty result does not always prove that an object is absent. Learn to recognize that uncertainty before reporting it as a fact.

Recognize Waiting Before Calling Everything Slow

A request can be running, waiting for a resource, or waiting behind another transaction. Learn to inspect active requests and follow blocking relationships. Do not begin by killing the session with the longest elapsed time.

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

Ask what changed, who is affected, and when the problem began. Capture timestamps and repeat the observation when appropriate. One sample can show a transient condition rather than a persistent cause.

Practice blocking with two lab sessions and a deliberately open transaction. Learn how to commit or roll it back cleanly. That small exercise makes lock waits less mysterious than a long list of definitions.

Learn the Files Behind the Database

Understand the purpose of data files, log files, and tempdb before moving or shrinking anything. Free space inside a file differs from free space on the disk. Log growth can be a symptom of another unresolved condition.

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

Read the error log and learn where backup and Agent job history live. Build a short inventory with owners and recovery expectations. Knowing whom to contact can matter as much as knowing the next query.

Let Advanced Topics Wait Their Turn

You do not need to master every availability feature or optimizer transformation during the first month. First become reliable at recovery, access checks, and evidence collection. Then add indexing, execution plans, and workload-specific skills.

Keep a weekly lab question and a short note describing what you learned. Include failed assumptions and the command that clarified them. A small collection of understood experiments is more useful than a folder of impressive scripts.

A good starting plan is not a race through features, it is practice at protecting data.

This post was rewritten from scratch in September 2026. The original, published on 2011-12-06, 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.