The Tools a DBA Installs on Day One

Your new DBA laptop is ready, but the first incident will not wait for a download. The tools a DBA installs should cover connection, scripting, recovery checks, and repeatable work.

Install SSMS From the Current Source

SQL Server Management Studio is the main Windows graphical tool for many DBA tasks. Install a supported release through the approved software channel. Record its version. SSMS has its own update cycle; patching the Database Engine does not patch every workstation.

I use SSMS for object exploration, plans, security review, backup and restore dialogs, and quick scripts. It can do much more, but day one is about a working connection and a familiar place to investigate. Test login to a nonproduction instance before a production alert arrives.

Which instance is the query window connected to? Make that visible in your habits. The most powerful tool on the laptop still needs the right target.

SELECT
    @@SERVERNAME AS ConnectedInstance,
    DB_NAME() AS CurrentDatabase,
    SERVERPROPERTY('ProductVersion') AS ProductVersion;

Add Command Line Utilities to the Tools a DBA Installs

Install the current Microsoft command line utilities when you need ODBC sqlcmd and bcp. These tools help with repeatable checks and bulk data movement. The Go based sqlcmd is a separate choice. Do not let two executables with the same name change a job through PATH order.

Check every executable that Windows finds. Record the full path and version of the one your scripts use. Test authentication and certificate behavior from the machine where the job will run. A DBA laptop result is not an application server result.

I keep a small command line check ready because graphical tools are not always available during a remote incident. That check should report the instance name before it reports anything else.

REM Command line
where.exe sqlcmd.exe
where.exe bcp.exe
bcp -v

Build a Small Script Library

Keep tested scripts for version, database state, backup history, active requests, blocking, file space, and restore checks. Each script should state what it reads, required permissions, and versions tested. Do not fill the library with scripts copied from a search result and never run.

I prefer a short, trusted kit to a folder of a thousand mysteries. A script with a clear output label saves time at midnight. A script that changes settings needs a different review and access path from a read only diagnostic query.

Include capture time and server identity in reports. A saved result without those fields becomes hard to trust after a failover or migration.

Use Managed Source Control

Put scripts and runbooks in the team’s managed source control system. The point is a reviewed history of changes and a known current version, not a pile of local copies with final in the file name. Protect access and keep credentials out of files.

Use a review process for scripts that alter data or configuration. A read only query can have a lighter path, but it still needs a description and test. Keep the script library in a location every authorized DBA can reach during an incident.

I have seen a clever script vanish with a laptop replacement. Versioned team storage is a quiet form of disaster recovery.

Know What Is Already Installed

Do not assume a full SQL Server feature pack is required on a DBA workstation. Install only the tools the role uses. Add a supported ODBC or OLE DB driver when a specific application or utility needs it. Keep the source and version record for each package.

A clean machine should have a standard software list. That makes replacement and onboarding repeatable. It also reduces surprise when a driver update changes encryption defaults. Test the new client path against a staging server before broad rollout.

Use Windows inventory and your software management tool for package details. SQL Server SERVERPROPERTY describes the engine, not every client component on the workstation.

Add a Recovery Check to the Tools a DBA Installs

A DBA needs a quick way to inspect backup state and a separate procedure to prove restore. Query msdb for recent full backup records, then verify the referenced files and restore them in a test environment. Backup history alone does not prove the file still exists.

The query below is a starting check for user databases. It reports what msdb recorded, not a verified recovery point. Keep that distinction in the script name and output. Add log backup checks where the recovery model requires them.

I test a restore early on a new assignment. A beautiful tool setup is not much comfort when the first recovery request arrives.

SELECT
    d.name AS DatabaseName,
    MAX(b.backup_finish_date) AS LastFullBackup
FROM sys.databases AS d
LEFT JOIN msdb.dbo.backupset AS b
  ON b.database_name = d.name
 AND b.type = 'D'
WHERE d.database_id > 4
GROUP BY d.name
ORDER BY d.name;

Keep Access Least Privileged

Use your organization’s approved identity and access process. Do not save production passwords in connection profiles or scripts without an approved secret store. Separate a read only diagnostic account from an account that can change the server when the role design supports it.

Test permissions before an incident. A script that requires server state access should say so. If it fails under your account, request the specific right rather than making every DBA a sysadmin for convenience.

I also check multi factor and remote access paths before an on call shift. A blocked login at midnight is not a database mystery.

Review the Tools a DBA Installs Each Quarter

The tools a DBA installs change. SSMS releases move, drivers receive security updates, and command line behavior can differ across versions. Review the installed set on a predictable schedule. Retest important scripts after client tool updates.

Remove tools that no longer serve the role. Keep the installation record and the tested script versions. A small supported kit is easier to maintain than a museum of retired utilities.

Day one ends when you can connect to the right instance, run a trusted check, find a backup, and share a reviewed script. Everything else can be added for a real need.

Related reading on this blog: SQL SERVER Tools I Use and Recommend (Updated: October 2020) and Reclaiming Space and Performance: Database Backup History.

A DBA toolkit is not a download collection, it is a set of tested ways to act under pressure.

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