Host and operating system
OS version and build, CPU cores and model, physical RAM, uptime and the active power plan. A host left on the Balanced power plan throttles CPU frequency, which looks like a database problem and is not.
Disk capacity and layout
Free space per volume, media type, and the NTFS allocation unit size. SQL Server data volumes should be formatted at 64 KB; the 4 KB default costs measurable throughput and stays invisible until somebody checks.
Version, edition and patch level
Build number, edition and cumulative update, checked against the Microsoft lifecycle so you know whether the instance is still supported and what the edition limits you to.
Instance configuration
Max server memory, MAXDOP and cost threshold for parallelism against the CPU and RAM actually present, including NUMA layout. Still at defaults on most estates we review.
tempdb configuration
File count, equal sizing, autogrowth and current space use. Unequal tempdb files cause allocation contention that presents as a query problem.
Database inventory and options
Every database with its size, recovery model and compatibility level, plus the options that quietly cause trouble: auto-close, auto-shrink, and any page verify setting other than CHECKSUM.
Backup coverage
Last full, differential and log backup per database, with the age of each. Databases with no backup at all are the single most common finding in this check.
Restore history
Restores actually performed on this instance, read from msdb. A script cannot prove a backup is restorable — but it can show whether anyone has ever tried, which is the question worth asking.
Log backup cadence
How often log backups really run across the last seven days, and the average interval between them. That interval is your genuine worst-case data loss, whatever the recovery objective says on paper.
Integrity checks
When DBCC CHECKDB last completed cleanly on each database. Corruption found late is often corruption already inside every backup you hold.
High availability configuration
Always On, failover clustering, mirroring and log shipping — what exists, and whether replicas are synchronising right now, including the redo queue depth on each.
File growth settings
Percentage-based autogrowth and unconstrained log files. A 10% growth increment on a 200 GB file is a 20 GB pause the first time it fires, usually at the worst possible moment.
Storage latency
Average read and write stall per file since startup. This is what separates a slow query problem from a slow disk problem, and the two get confused constantly.
Wait statistics
What the instance is actually waiting on, with idle and benign waits filtered out — so you see where the time goes rather than where you assume it goes.
Index health
Fragmentation on indexes large enough to matter, plus indexes nobody reads that every insert still has to maintain. Collected in LIMITED mode, which is safe during business hours.
Missing index pressure
What the optimiser has been asking for, weighted by impact. Evidence to review, never applied as written — it suggests one index per query with no regard for the ones already there.
Statistics currency
How stale the statistics are and how many rows have changed since. Stale statistics produce bad plans that look exactly like a hardware problem.
Expensive queries and blocking
The queries costing the most CPU and reads across the instance, anything blocking at the time of collection, and the deadlocks recorded by the always-on system health session.
SQL Agent job health
Failed and long-running jobs, jobs with no failure notification configured at all, and jobs still owned by accounts belonging to people who have left.
Security and encryption
Who holds sysadmin, the state of the sa account, which surface-area features are enabled, TDE status, and whether connections are actually encrypted in transit.
