The first hour with an inherited server is for finding what can hurt you tomorrow. A health check for an inherited server starts with recovery and access, then checks the quiet failures.
Confirm What You Own in an Inherited Server Health Check
Record the instance name, version, edition, uptime, databases, and server role before changing anything. An inherited server can be part of an availability group or feed another application through a linked server. A familiar machine name does not reveal all dependencies. Ask the owner what service depends on this instance and what outage window exists.
I begin read-only. That gives me a clear starting snapshot and avoids disturbing a system whose history I do not know. The first hour is for identifying urgent risks and owners, not optimizing every knob. If you cannot describe the server’s purpose, postpone changes that can affect its workload.
SELECT @@SERVERNAME AS instance_name,
SERVERPROPERTY(N'ProductVersion') AS product_version,
SERVERPROPERTY(N'Edition') AS edition,
sqlserver_start_time
FROM sys.dm_os_sys_info;Inspect Recent Backups
Query msdb backup history for each database and compare it with the stated recovery objective. A recent full backup alone does not satisfy point-in-time recovery for a FULL database. Check log backup cadence and job status. Confirm where backup files are stored and whether the team has restored from them recently. A backup that nobody can locate under pressure is a weak comfort.
I ask for the most recent successful restore test. If there is none, I put that near the top of the follow-up list. Do not assume the oldest backup history row describes retention; msdb history can be pruned independently of the files. Validate the actual backup chain and storage.
SELECT d.name AS database_name,
d.recovery_model_desc,
MAX(CASE WHEN b.type = N'D' THEN b.backup_finish_date END) AS last_full,
MAX(CASE WHEN b.type = N'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
GROUP BY d.name, d.recovery_model_desc
ORDER BY d.name;Read Errors Before Tuning
Read the current SQL Server error log for backup failures, I/O errors, failed starts, memory warnings, and availability messages. Search previous logs if the service restarted recently. A clean current log can hide the event that caused the restart. Check Windows event logs through the approved operations process when the SQL log points outside the engine.
I have found the real first-hour priority in an error log while dashboards looked green. An alert can have been disabled or routed to an old address. Note recurring messages and their timestamps, then connect them to jobs and incidents. Avoid treating every informational message as a crisis. The aim is to find evidence of a current risk.
Review Access Paths
List sysadmin members, disabled logins, and database owners. Include Windows groups and ask for their nested memberships. An account name alone does not tell you who can enter the server. Identify shared service accounts and emergency access procedures. Keep this inspection read-only until you know what jobs and applications depend on each login.
I ask who approves access changes. If nobody owns the list, that is a finding in itself. An old login can remain because a quarterly process still uses it, so a short connection sample does not justify immediate removal. Record a review item with a proposed test and rollback plan. Security improvement should not begin with a surprise outage.
Check Settings and Capacity
Capture max server memory, parallelism settings, tempdb layout, file growth rules, and free storage capacity. Review database recovery model, page verification, AUTO_CLOSE, and AUTO_SHRINK. Look for values that conflict with the workload or recovery plan. Do not change a setting solely because it differs from a generic recommendation.
The query below catches a few database-level exceptions quickly. A result row means investigate, not alter immediately. The system can have an intentional development database on the same instance. Tie each concern to the database owner and service purpose.
SELECT name,
recovery_model_desc,
page_verify_option_desc,
is_auto_close_on,
is_auto_shrink_on,
SUSER_SNAME(owner_sid) AS owner_name
FROM sys.databases
WHERE database_id > 4
ORDER BY name;Read Agent Jobs
Check failed and disabled SQL Agent jobs. A job can be disabled on purpose during migration, or it can be forgotten after an incident. Review job owner, schedule, last outcome, and the task it performs. Pay special attention to backups, integrity checks, index maintenance, and data movement. A green SQL Server service does not mean the work around it is running.
I compare job names with the operations runbook. The gap between those lists tells you what has no owner or no documentation. Do not enable every disabled job in the first hour. Confirm the schedule and downstream effects first. An old import can wake up and write to the wrong target with admirable enthusiasm.
Sort Inherited Server Health Check Findings by Consequence
Write a short list of immediate risks, next-week investigations, and routine improvements. Missing backups, corruption messages, and uncontrolled sysadmin access deserve attention before a cosmetic server setting. Record the evidence for each item and the person who owns the decision. A health check for an inherited server needs an action plan that survives the next shift change.
I avoid a score that hides the reason behind it. A server with one failed backup job can have a better score than a server with twenty minor warnings and still be the one needing urgent work. Describe the practical consequence. Then the owner can choose the right response and timing.
Leave a Repeatable Inherited Server Health Check Record
Save the queries, snapshots, dates, and follow-up actions in the operations documentation. Mark what you verified and what remains unknown. Do not write that restores are good because a backup history row exists. Do not write that security is reviewed because sysadmin members were listed. Each conclusion needs its own evidence.
What would the next DBA need if you were unavailable tonight? Answer that with a one-page server identity, recovery summary, alert route, access owner, and open risks. The first-hour health check for an inherited server is useful when it leads to that shared understanding. The server should become less mysterious each time it is reviewed.
Confirm a Recovery Contact
Name the person who can approve an emergency restore and the team that owns backup storage. Test the contact route outside normal hours. I put that information beside the latest restore evidence because recovery needs technical access and decision authority at the same time. A healthy backup file is not enough if nobody can reach the storage or approve the action. Record missing contacts as open risks. Ask how the instance would be rebuilt if its host failed tonight. That question reveals missing certificates, service accounts, and configuration records before a real outage forces the team to improvise.
Related reading on this blog: A Monthly Health Check You Can Run in Ten Minutes and Database Performance Health Check: Six Months Slow, Fixed in 75 Minutes.
An inherited server is not healthy because it starts, it is healthy when its recovery and controls are proven.
Published by Pinal Dave on SQLAuthority. More of my work at pinaldave.com.
