sql server hub / environment assessment guide

SQL Serverenvironment assessment guide

A SQL Server environment assessment records the current state of a SQL Server setup before cleanup, migration, upgrade, or support handover work starts.

Use it for older production servers, handed-over systems, or environments with thin documentation where versions, databases, backups, jobs, alerts, access, linked servers, and HA/DR paths need to be checked from SQL Server output.

Guide

Operational guide~15 min readUpdated 19 Apr 2026

Share

LinkedInXEmail
  1. 01What a SQL Server environment assessment is
  2. 02When a SQL Server environment assessment is useful
  3. 03SQL Server assessment scope and permissions
  4. 04SQL Server version, edition, and support status
  5. 05SQL Server databases, files, and recovery models
  6. 06SQL Server backup and restore review
  7. 07SQL Server Agent jobs and failed job history
  8. 08SQL Server alerts, operators, and monitoring gaps
  9. 09SQL Server logins, roles, and database access
  10. 10SQL Server linked servers, credentials, and dependencies
  11. 11SQL Server HA, DR, failover, and replication review
  12. 12What not to change during the first SQL Server assessment
  13. 13When a SQL Server health audit helps

What a SQL Server environment assessment is

A SQL Server environment assessment is a structured, read-only pass over the SQL Server instance, its databases, SQL Agent work, backup and restore history, access model, dependencies, and HA/DR configuration.

The useful output is a map of the current setup: what exists, what has recent SQL Server history behind it, what is missing, what needs a test, and which changes need more context before anyone touches them.

In a handed-over SQL Server, the assessment should separate routine noise from production risk: unsupported builds, stale backups, failed jobs, unowned alerts, excessive access, linked-server dependencies, weak restore history, and HA/DR paths that have not been checked recently.

Assessment areaWhat to record
InstanceVersion, edition, patch level, startup time, cluster/AG context, and configuration settings that need an owner or explanation.
DatabasesState, recovery model, compatibility level, owner, file layout, growth settings, and log reuse wait reason.
OperationsBackup history, restore history, SQL Agent jobs, failed job output, alerts, operators, and maintenance gaps.
Access and dependenciesServer roles, database users, orphaned users, linked servers, credentials, proxies, and external paths.
HA and DRAvailability Group, log shipping, replication, failover, restore, and dependency paths that need validation.

When a SQL Server environment assessment is useful

Run an assessment before another DBA, IT department, or vendor takes responsibility, before a migration or upgrade, after repeated incidents, or when documentation no longer matches what the server is doing.

The first pass should be read-only. It should give people responsible for the SQL Server a usable map before they change settings, clean access, rewrite jobs, move files, or tune queries.

1

A production SQL Server was handed over with thin documentation.

2

A migration, upgrade, patch, or audit is coming and the current state is not documented well enough.

3

Backups, jobs, alerts, and permissions exist, but nobody is sure whether they still match the business need.

4

A vendor, contractor, or former DBA owned important context that is no longer available.

5

The same incidents keep returning and the team needs a clearer first map.

SQL Server assessment scope and permissions

Start by deciding which instance, databases, jobs, linked servers, and HA/DR features are in scope. Then collect the instance facts that make later output interpretable: server name, edition, version, cluster state, HA feature state, uptime, CPU count, and memory.

Some catalog views and DMVs require metadata access, VIEW SERVER STATE, VIEW SERVER SECURITY STATE, msdb access, or SQL Server 2022 performance-state permissions. Low-permission output can look cleaner than the server really is.

How to check SQL Server version and instance context

Reads version, edition, clustered state, HADR state, uptime, CPU count, and committed memory.

SELECT
    SERVERPROPERTY('ServerName') AS server_name,
    SERVERPROPERTY('MachineName') AS machine_name,
    SERVERPROPERTY('InstanceName') AS instance_name,
    SERVERPROPERTY('Edition') AS edition,
    SERVERPROPERTY('ProductVersion') AS product_version,
    SERVERPROPERTY('ProductLevel') AS product_level,
    SERVERPROPERTY('ProductUpdateLevel') AS product_update_level,
    SERVERPROPERTY('ProductUpdateReference') AS product_update_reference,
    SERVERPROPERTY('IsClustered') AS is_clustered,
    SERVERPROPERTY('IsHadrEnabled') AS is_hadr_enabled,
    osi.sqlserver_start_time,
    osi.cpu_count,
    osi.committed_kb / 1024 AS committed_mb
FROM sys.dm_os_sys_info AS osi;

ProductVersion and ProductUpdateLevel show the build family before you judge patch posture. sqlserver_start_time tells you how long DMV counters may have been collecting. IsClustered and IsHadrEnabled help decide which HA/DR checks matter next.

How to check SQL Server configuration context

Reads high-impact configuration settings often reviewed during an environment assessment.

SELECT
    name,
    value,
    value_in_use,
    description,
    is_dynamic,
    is_advanced
FROM sys.configurations
WHERE name IN (
    N'max server memory (MB)',
    N'min server memory (MB)',
    N'max degree of parallelism',
    N'cost threshold for parallelism',
    N'backup compression default',
    N'xp_cmdshell',
    N'clr enabled',
    N'Ad Hoc Distributed Queries',
    N'remote admin connections'
)
ORDER BY name;

Do not change configuration from this list alone. Use it to identify settings that need an owner, a reason, and a test plan before adjustment.

SQL Server version, edition, and support status

Version and edition shape the rest of the assessment. They affect supported upgrade paths, Query Store behavior, HA features, encryption options, DMV permissions, and whether the instance is already outside normal support.

Record the exact build, not only the major version. Then compare it with the SQL Server latest updates tracker and the SQL Server upgrade guide if a version change is likely.

SQL Server databases, files, and recovery models

Database state, recovery model, compatibility level, owner, file paths, and growth settings show what is running and where production risk may already be visible.

How to inventory databases and recovery models

Lists user databases with state, recovery model, compatibility level, owner, page verification, and log reuse wait.

SELECT
    d.name AS database_name,
    d.state_desc,
    d.user_access_desc,
    d.recovery_model_desc,
    d.compatibility_level,
    SUSER_SNAME(d.owner_sid) AS database_owner,
    d.is_read_only,
    d.is_auto_close_on,
    d.is_auto_shrink_on,
    d.page_verify_option_desc,
    d.log_reuse_wait_desc
FROM sys.databases AS d
WHERE d.database_id > 4
ORDER BY d.name;

FULL recovery without log backups is a recovery and log-growth problem. AUTO_CLOSE and AUTO_SHRINK are usually red flags on production databases. Database owner and compatibility level often explain old behavior after handoff.

How to check database files and growth settings

Lists database files, physical paths, size, max size, and growth settings.

SELECT
    DB_NAME(mf.database_id) AS database_name,
    mf.type_desc,
    mf.name AS logical_name,
    mf.physical_name,
    CONVERT(decimal(18,2), mf.size * 8.0 / 1024) AS size_mb,
    CASE
        WHEN mf.max_size = -1 THEN N'Unlimited'
        ELSE CONVERT(nvarchar(30), CONVERT(decimal(18,2), mf.max_size * 8.0 / 1024))
    END AS max_size_mb,
    CASE
        WHEN mf.is_percent_growth = 1 THEN CONVERT(nvarchar(30), mf.growth) + N'%'
        ELSE CONVERT(nvarchar(30), CONVERT(decimal(18,2), mf.growth * 8.0 / 1024)) + N' MB'
    END AS growth_setting
FROM sys.master_files AS mf
WHERE mf.database_id > 4
ORDER BY database_name, mf.type_desc, mf.file_id;

Percent growth and unlimited files need review on older or poorly maintained environments. Physical paths reveal drive layout, shared storage assumptions, and migration dependencies. Do not move or resize files from this output alone; check workload timing and backups first.

SQL Server backup and restore review

Backup history tells you whether backup files were produced. Restore history tells you whether SQL Server has recently restored anything on the instance. Neither confirms that an application can run from the restored database or that the restore timing is acceptable.

How to check recent backup coverage

Shows last full, differential, and log backup timestamps for each user database.

WITH LastBackups AS (
    SELECT
        bs.database_name,
        MAX(CASE WHEN bs.type = 'D' THEN bs.backup_finish_date END) AS last_full_backup,
        MAX(CASE WHEN bs.type = 'I' THEN bs.backup_finish_date END) AS last_differential_backup,
        MAX(CASE WHEN bs.type = 'L' THEN bs.backup_finish_date END) AS last_log_backup
    FROM msdb.dbo.backupset AS bs
    WHERE bs.backup_finish_date >= DATEADD(day, -30, SYSDATETIME())
    GROUP BY bs.database_name
)
SELECT
    d.name AS database_name,
    d.recovery_model_desc,
    lb.last_full_backup,
    lb.last_differential_backup,
    lb.last_log_backup,
    DATEDIFF(hour, lb.last_full_backup, SYSDATETIME()) AS hours_since_last_full,
    DATEDIFF(minute, lb.last_log_backup, SYSDATETIME()) AS minutes_since_last_log
FROM sys.databases AS d
LEFT JOIN LastBackups AS lb
    ON lb.database_name = d.name
WHERE d.database_id > 4
ORDER BY d.name;

A missing full backup is a serious assessment finding. A FULL or BULK_LOGGED database usually needs regular log backups. Compare timestamps with the agreed recovery-point target before changing backup cadence.

How to check restore history

Reads recent restore operations, source backup timing, restore type, recovery flag, and file path where available.

SELECT TOP (100)
    rh.destination_database_name,
    rh.restore_date,
    rh.restore_type,
    rh.replace,
    rh.recovery,
    bs.database_name AS source_database_name,
    bs.backup_start_date,
    bs.backup_finish_date,
    bmf.physical_device_name
FROM msdb.dbo.restorehistory AS rh
LEFT JOIN msdb.dbo.backupset AS bs
    ON bs.backup_set_id = rh.backup_set_id
LEFT JOIN msdb.dbo.backupmediafamily AS bmf
    ON bmf.media_set_id = bs.media_set_id
ORDER BY rh.restore_date DESC;

Recent restore history can show test restores, refreshes, incidents, or migrations. No restore history on this instance does not mean restores never happened elsewhere. Use this with restore-test notes and backup file access before claiming recovery readiness.

SQL Server Agent jobs and failed job history

SQL Agent jobs often contain the hidden operating model: backups, ETL, index work, CHECKDB, cleanup, report loads, vendor tasks, and notification behavior.

How to inventory SQL Agent jobs

Lists jobs, owners, enabled state, job steps, subsystems, target database, and command text.

SELECT
    j.name AS job_name,
    SUSER_SNAME(j.owner_sid) AS job_owner,
    j.enabled,
    j.date_created,
    j.date_modified,
    s.step_id,
    s.step_name,
    s.subsystem,
    s.database_name,
    s.command
FROM msdb.dbo.sysjobs AS j
LEFT JOIN msdb.dbo.sysjobsteps AS s
    ON s.job_id = j.job_id
ORDER BY j.name, s.step_id;

Job owner, subsystem, and command text show who or what the job depends on. Disabled jobs may be intentional, abandoned, or waiting for a business window. Do not delete or rewrite jobs before mapping downstream dependencies.

How to find recent SQL Agent job failures

Reads failed, retrying, and canceled SQL Agent history from the last 14 days.

SELECT TOP (100)
    j.name AS job_name,
    h.step_id,
    h.step_name,
    h.run_status,
    msdb.dbo.agent_datetime(h.run_date, h.run_time) AS run_datetime,
    h.run_duration,
    h.sql_severity,
    h.sql_message_id,
    h.message
FROM msdb.dbo.sysjobhistory AS h
JOIN msdb.dbo.sysjobs AS j
    ON j.job_id = h.job_id
WHERE h.run_status IN (0, 2, 3)
  AND msdb.dbo.agent_datetime(h.run_date, h.run_time) >= DATEADD(day, -14, SYSDATETIME())
ORDER BY run_datetime DESC;

A job failure that nobody noticed is an alerting problem as well as a job problem. Run duration and step name help separate recurring noise from real maintenance, backup, or data-load gaps. Job naming varies, so CHECKDB and maintenance checks may need local naming review.

SQL Server alerts, operators, and monitoring gaps

Alerts matter only when they reach someone who knows what to do next. Check whether SQL Agent alerts exist, whether operators are enabled, and whether notification routing still matches the support model.

How to check SQL Agent alerts and operators

Lists SQL Agent alerts, severity/message settings, notification routing, operators, and email addresses.

SELECT
    a.name AS alert_name,
    a.enabled AS alert_enabled,
    a.message_id,
    a.severity,
    a.delay_between_responses,
    a.has_notification,
    o.name AS operator_name,
    o.enabled AS operator_enabled,
    o.email_address,
    n.notification_method
FROM msdb.dbo.sysalerts AS a
LEFT JOIN msdb.dbo.sysnotifications AS n
    ON n.alert_id = a.id
LEFT JOIN msdb.dbo.sysoperators AS o
    ON o.id = n.operator_id
ORDER BY a.name, o.name;

Disabled alerts or disabled operators can explain silent incidents. Severity and message-id alerts should match the environment's actual support path. Use the monitoring guide when alerting needs a broader baseline and runbook review.

SQL Server logins, roles, and database access

Access review starts with who can connect, who has fixed server roles, which database users map to logins, and whether old support or vendor access is still active.

How to review server logins and server roles

Lists SQL, Windows login, and Windows group principals with fixed server role membership.

SELECT
    sp.name AS principal_name,
    sp.type_desc,
    sp.is_disabled,
    sp.default_database_name,
    spr.name AS server_role
FROM sys.server_principals AS sp
LEFT JOIN sys.server_role_members AS srm
    ON srm.member_principal_id = sp.principal_id
LEFT JOIN sys.server_principals AS spr
    ON spr.principal_id = srm.role_principal_id
WHERE sp.type IN ('S', 'U', 'G')
ORDER BY sp.name, spr.name;

sysadmin membership deserves a named reason and an owner. Windows groups can hide broad access; review group membership outside SQL Server too. Do not disable access until job ownership, application use, and emergency paths are understood.

How to review database users and orphaned users

Run inside each important database to list users, database roles, and matching server principals.

SELECT
    DB_NAME() AS database_name,
    dp.name AS database_principal,
    dp.type_desc,
    dp.authentication_type_desc,
    dp.default_schema_name,
    rp.name AS database_role,
    sp.name AS matching_server_principal
FROM sys.database_principals AS dp
LEFT JOIN sys.database_role_members AS drm
    ON drm.member_principal_id = dp.principal_id
LEFT JOIN sys.database_principals AS rp
    ON rp.principal_id = drm.role_principal_id
LEFT JOIN sys.server_principals AS sp
    ON sp.sid = dp.sid
WHERE dp.type IN ('S', 'U', 'G')
  AND dp.principal_id > 4
ORDER BY dp.name, rp.name;

A null matching_server_principal can point to an orphaned SQL user or contained-database behavior. db_owner membership needs review before cleanup. Run this per database; server-level output alone is not enough.

SQL Server linked servers, credentials, and dependencies

Linked servers, credentials, proxies, file shares, SSIS packages, and external procedures are common handoff surprises. They can turn a small SQL Server change into an application or integration outage.

How to inventory linked servers

Lists linked servers, providers, data sources, remote-login behavior, and linked-login mappings.

SELECT
    s.name AS linked_server_name,
    s.product,
    s.provider,
    s.data_source,
    s.is_linked,
    s.is_remote_login_enabled,
    ll.local_principal_id,
    SUSER_SNAME(ll.local_principal_id) AS local_principal_name,
    ll.uses_self_credential,
    ll.remote_name
FROM sys.servers AS s
LEFT JOIN sys.linked_logins AS ll
    ON ll.server_id = s.server_id
WHERE s.server_id <> 0
ORDER BY s.name, local_principal_name;

Remote data sources are migration and outage dependencies. Linked-login mappings can carry sensitive access assumptions. Inventory output does not test whether the remote side still works.

How to inventory credentials and proxies

Lists SQL Server credentials and SQL Agent proxy mappings where visible.

SELECT
    c.name AS credential_name,
    c.credential_identity,
    p.name AS proxy_name,
    p.enabled AS proxy_enabled,
    sp.name AS proxy_login
FROM sys.credentials AS c
LEFT JOIN msdb.dbo.sysproxies AS p
    ON p.credential_id = c.credential_id
LEFT JOIN msdb.dbo.sysproxylogin AS pl
    ON pl.proxy_id = p.proxy_id
LEFT JOIN sys.server_principals AS sp
    ON sp.sid = pl.sid
ORDER BY c.name, p.name, sp.name;

Credentials and proxies often support ETL, file access, PowerShell, CmdExec, SSIS, or vendor jobs. Do not rotate or remove credentials until dependent jobs and owners are mapped. Some secrets and external dependencies cannot be recovered from SQL metadata alone.

SQL Server HA, DR, failover, and replication review

HA and DR checks show whether the environment has a second path, not whether that path works under pressure. The assessment should record what is configured and what still needs a drill.

How to check HA and DR context

Reads Availability Group replica state and log shipping metadata where those features are configured.

SELECT
    ag.name AS availability_group_name,
    ar.replica_server_name,
    ars.role_desc,
    ars.connected_state_desc,
    ars.synchronization_health_desc,
    ar.availability_mode_desc,
    ar.failover_mode_desc
FROM sys.availability_groups AS ag
JOIN sys.availability_replicas AS ar
    ON ar.group_id = ag.group_id
LEFT JOIN sys.dm_hadr_availability_replica_states AS ars
    ON ars.replica_id = ar.replica_id
ORDER BY ag.name, ar.replica_server_name;

SELECT
    primary_database,
    backup_directory,
    backup_share,
    backup_retention_period,
    monitor_server
FROM msdb.dbo.log_shipping_primary_databases
ORDER BY primary_database;

SELECT
    secondary_database,
    primary_server,
    restore_delay,
    restore_mode,
    disconnect_users
FROM msdb.dbo.log_shipping_secondary_databases
ORDER BY secondary_database;

Empty result sets can simply mean the feature is not configured on this instance. Availability Group health and log shipping metadata still need listener, job, backup, and restore validation. Use the failover and recovery guides when a configured HA/DR path needs deeper review.

What not to change during the first SQL Server assessment

1

Do not disable old logins, jobs, linked servers, credentials, or alerts before mapping dependencies.

2

Do not change recovery models, backup cadence, cleanup retention, or file locations from one query result.

3

Do not tune indexes, MAXDOP, memory, or compatibility level while the basic operating model is still unclear.

4

Do not assume backup history means restore readiness.

5

Do not treat missing documentation as permission to rebuild everything at once.

6

Do not make a migration, patch, or hardening plan until rollback and support paths are understood.

When a SQL Server health audit helps

A health audit helps when the first assessment finds several connected risks: stale backups, failed jobs, unclear alert routing, broad access, linked-server dependencies, unsupported builds, or HA/DR paths that have not been tested.

Send version output, database inventory, backup and restore history, job failures, alert routing, access findings, linked-server output, and any planned change window. That is enough to decide what to fix first without turning the review into guesswork.

Next step

If the assessment finds several connected gaps, use the SQL Server health audit page or request the review above.

Next useful reads: the SQL Server health check guide, the SQL Server backup guide, the SQL Server maintenance plan guide, and the SQL Server hardening guide.