The database is down, and you are not in the building. Remote DBA work goes well when access, server context, change authority, and communication were settled before that call.
Prepare Remote DBA Access Before an Incident
Remote work depends on reliable, approved access. Know the network path, multifactor process, jump host, and account needed for each server. Test those paths during normal hours. Keep a separate emergency access procedure with an owner and audit trail. An access method that works only from one person’s laptop is a single point of failure.
I check whether the account can read diagnostic views and whether write access requires a separate approval. That separation reduces accidental changes during investigation. Which permission will be needed for a restore? Verify it in a scheduled drill, not while users wait for recovery.
Build a Server Map
Keep a concise map of instances, databases, applications, owners, environments, backup locations, and dependencies. Include which servers are production and which are disposable. A remote query window makes it easy to connect to a similarly named instance. A map and connection naming standard reduce that risk.
I put an identity check at the top of reusable scripts. The query is deliberately boring. It prevents a surprising number of mistakes. Keep the result with the incident note so the evidence can be tied to the right server.
SELECT @@SERVERNAME AS connected_server,
DB_NAME() AS current_database,
SUSER_SNAME() AS current_login;Use Remote DBA Runbooks That Work at a Distance
A runbook should state the symptom, first read-only checks, escalation contact, permitted actions, expected output, and rollback. Include storage paths and certificate dependencies for restores. Do not include passwords. A runbook that says “ask Pat” stops working when Pat is offline. Test a procedure with someone who did not write it.
I keep the first steps short enough to follow during a call. A remote DBA can lose time switching between chat messages, dashboards, and a query editor. Put the server context and decision points in one place. Which step requires the application owner? Make that handoff explicit.
Agree on Change Windows and Authority
Know which changes need a maintenance window, who approves them, and how emergency work is authorized. A remote DBA should not infer approval from a hurried message that something is slow. Confirm the target, script, backup state, rollback, and verification before executing a write. Record who approved the change and when.
I send a short statement of the intended action before it begins and a result afterward. That is not bureaucracy for its own sake. It keeps the team synchronized when nobody can see the other person’s screen. If a plan changes mid-incident, say so and obtain the right decision.
Capture Evidence Before It Moves
Blocking chains, wait types, and active requests can change within seconds. Capture the time, server, database, and relevant session details before changing settings or ending sessions. Avoid treating one snapshot as the whole incident. For recurring problems, configure a supported monitoring method that retains enough history.
The query below gives a current view of active requests. It is read only and incomplete by design. A session can finish before the next query. I pair this output with application reports and event timing.
SELECT session_id, status, command, wait_type,
blocking_session_id, total_elapsed_time
FROM sys.dm_exec_requests
WHERE session_id <> @@SPID
ORDER BY total_elapsed_time DESC;Communicate in Plain Updates
Say what is affected, what is known, what is being checked, and when the next update will come. Avoid promising a fix time before the cause is understood. If a change needs application validation, ask for a named tester. Remote work has fewer hallway conversations, so silence can look like inactivity even when investigation is careful.
I keep updates short. The technical detail belongs in the incident record, where another DBA can inspect it. Which decision does the manager need now? Lead with that. A long list of wait types is not a useful status report for a sales team waiting on orders.
Close Remote DBA Work With Verification and Handoff
After a repair, check the database, application path, backup state, and alerts. A query returning successfully does not prove every user workflow recovered. Record the final change, evidence, remaining risks, and who owns follow-up. Revoke temporary access when the approved window closes.
I ask a local or application owner to confirm the user-facing result. Then I update the runbook if it missed a step. Good remote work leaves the team with a clearer map than it had before the incident. Distance should not make the change invisible.
Remote DBA work depends on a visible handoff. Record which instances were checked, what changed, what remains open and who will respond if an alert fires after your working hours. Include time zones and escalation contacts in the runbook. I do not assume that a green dashboard means the receiving team knows about a failed overnight restore test. A short written update prevents the context from disappearing when the video call ends.
Security also changes with distance, but the principles are ordinary: use approved access, least privilege, auditable sessions and protected transfer paths. Do not save credentials in a convenient local script. For a production change, agree on a rollback owner before touching the instance. If the connection drops at the wrong moment, the team should still know the server’s state and the next step.
I schedule a brief verification after a remote change, using the same evidence I would collect on site: service state, job results, application check and monitoring. Working remotely should not mean declaring completion because the command window closed. The result needs to be observable by the people who will support it.
Time boundaries matter. An after-hours escalation path should name who is available, what severity triggers contact and which actions are authorized without a meeting. I avoid relying on an informal chat message to carry that policy. A remote operator who knows the exact decision boundary can respond quickly and leave a clear record. Everyone else gets a chance to sleep, which is a respectable reliability feature.
Related reading on this blog: Remote Monitoring While Working from Home and Consulting 101: Why Do I Never Take Control of Computers Remotely? SQL Server Performance Tuning.
Remote DBA work is not a distant query window, it is disciplined access and visible decisions.
Published by Pinal Dave on SQLAuthority. More of my work at pinaldave.com.
