SQL Server weekly review checklist

Week ending: ____________________

Instances reviewed: ________________________________________________

Status: ☐ OK    ☐ Follow up    ☐ Urgent

DoneCheckFollow up when
1. SQL Server Agent jobs
Every expected run finished in its normal window and notifications arrived
A run is missing, failed, retried, unusually slow, or unreported
2. Backups and restore tests
Backup coverage matches the recovery plan and a recent restore test succeeded
The recovery target was missed or the latest restore test is stale, slow, or failed
3. Database integrity
Every database is covered by the intended CHECKDB schedule
A database was skipped, the check stopped early, or CHECKDB reported errors
4. Capacity and file growth
Storage growth is understood and there is enough time to act
A volume may fill, autogrowth keeps repeating, or log and tempdb growth has no clear cause
5. Query performance
Comparable workloads still use roughly the same time and resources
A query, plan, or workload became materially slower or more expensive
6. Blocking, deadlocks, and waits
Contention is understood and recurring patterns have been captured
The same blocker, object, deadlock, or wait pattern keeps returning
7. Logs and alert delivery
Important log entries were reviewed and alert routes reached a real recipient
An error needs action or a notification stopped before the final recipient
8. HA and data movement
Replicas are moving data within target and failover dependencies are in place
A queue is outside target, movement stopped, or a secondary is missing jobs, logins, or backups
9. Recent changes
Deployments and temporary changes were validated and closed
A new symptom matches a change or temporary work has no owner or removal date
10. Next-week actions
Every exception has a clear next step, owner, and date
A production risk or recurring problem remains unassigned

Weekly review record

Week ending:
SQL Server instances reviewed:
Status: OK / Follow up / Urgent

Failed or slow jobs:
Backup or restore concerns:
CHECKDB gaps or errors:
Capacity and file-growth concerns:
Performance regressions:
Blocking or deadlocks:
Log or alert problems:
HA/replication concerns:
Recent changes needing follow-up:

Next action | Owner | Due date

SQL Server operations

SQL Server weekly review checklist

A weekly SQL Server review gives the DBA time to look past individual alerts and check how the SQL Server instance behaved over the last seven days. Use this checklist to find missed work, recurring failures, and slow changes in capacity or performance before a small issue turns into a bigger one.

SQL Server weekly checklist: 10 checks

Use the same ten checks each week, but spend your time on exceptions. Mark each production instance or service group OK, Follow up, or Urgent. The review is finished when every exception has a next step, an owner, and a date.

Ten checks in the SQL Server weekly review checklist
CheckWhat you are trying to confirmFollow up when
1. SQL Server Agent jobsEvery expected run finished in its normal window and notifications arrivedA run is missing, failed, retried, unusually slow, or unreported
2. Backups and restore testsBackup coverage matches the recovery plan and a recent restore test succeededThe recovery target was missed or the latest restore test is stale, slow, or failed
3. Database integrityEvery database is covered by the intended CHECKDB scheduleA database was skipped, the check stopped early, or CHECKDB reported errors
4. Capacity and file growthStorage growth is understood and there is enough time to actA volume may fill, autogrowth keeps repeating, or log and tempdb growth has no clear cause
5. Query performanceComparable workloads still use roughly the same time and resourcesA query, plan, or workload became materially slower or more expensive
6. Blocking, deadlocks, and waitsContention is understood and recurring patterns have been capturedThe same blocker, object, deadlock, or wait pattern keeps returning
7. Logs and alert deliveryImportant log entries were reviewed and alert routes reached a real recipientAn error needs action or a notification stopped before the final recipient
8. HA and data movementReplicas are moving data within target and failover dependencies are in placeA queue is outside target, movement stopped, or a secondary is missing jobs, logins, or backups
9. Recent changesDeployments and temporary changes were validated and closedA new symptom matches a change or temporary work has no owner or removal date
10. Next-week actionsEvery exception has a clear next step, owner, and dateA production risk or recurring problem remains unassigned

Set up the weekly review before you start

Pick a complete seven-day window and use the same cutoff each week. Keep the previous equivalent week available for comparison. Month end, overnight imports, reporting cycles, and other scheduled workloads can change the numbers enough to make a quiet week a poor baseline.

Start with an inventory of the instances, databases, expected jobs, recovery targets, HA roles, monitoring locations, and owners. Gather the result for every expected system. A missing row is a finding until you know why it is missing; it can mean a new database was never added to a job or that history was removed before the review.

Use a login with the read-only monitoring access needed for the relevant system views, msdb history, Query Store, and HA views. Some checks need VIEW SERVER STATE or SQL Server Agent roles. If access hides part of the result, record that limit instead of marking the check OK.

Collect first and review by exception. Keep production changes, restore tests, failovers, and heavy integrity work in their own approved windows. The checklist is for self-managed SQL Server on Windows or Linux. Azure SQL Managed Instance shares several checks, but its backup and HA responsibilities differ. Use the daily operations checklist for failures that need attention now.

  • Use one fixed seven-day window.
  • Collect every expected instance and database.
  • Compare with the previous equivalent workload period.
  • Record exceptions and access gaps without changing production during the review.

Make sure scheduled jobs really ran

SQL Server Agent can finish a job after a retry, skip a scheduled run, or complete later than usual without creating an obvious current alert. The weekly review compares the work that should have run with the history Agent actually kept.

Where to look

SQL Server Agent in SSMS under Jobs and View History, plus msdb.dbo.sysjobs, sysjobhistory, and the Agent error log.

How to check it

  1. 1.Export the expected enabled jobs and schedules. Check that Agent history still reaches the start of the seven-day window.
  2. 2.Run the query below and match each expected run to an outcome. Open the full step message for failures, retries, cancellations, and unexpected step flow.
  3. 3.Compare duration with the same job during a similar workload period. Confirm that a real operator, mailbox, or ticket route received the failure notification.

What the result means

A missing run is different from a failed run: it may point to a disabled schedule, stopped Agent service, role-aware job logic, or lost history. A successful outcome with retried steps still needs review when the retry affected timing or downstream work.

Seven days of SQL Server Agent history

Returns completed job outcomes, then failed, retried, and canceled steps from msdb. Run it on each SQL Server instance.

USE msdb;

-- Completed job outcomes during the last seven days.
SELECT
    j.name AS job_name,
    CASE h.run_status
        WHEN 0 THEN 'Failed'
        WHEN 1 THEN 'Succeeded'
        WHEN 2 THEN 'Retry'
        WHEN 3 THEN 'Canceled'
        WHEN 4 THEN 'In progress'
    END AS run_status,
    dbo.agent_datetime(h.run_date, h.run_time) AS run_start_time,
    ((h.run_duration / 10000) * 3600)
      + (((h.run_duration % 10000) / 100) * 60)
      + (h.run_duration % 100) AS duration_seconds,
    h.message
FROM dbo.sysjobhistory AS h
JOIN dbo.sysjobs AS j
    ON j.job_id = h.job_id
WHERE h.step_id = 0
  AND h.run_date >= CONVERT(int, CONVERT(char(8), DATEADD(day, -7, GETDATE()), 112))
ORDER BY run_start_time DESC;

-- Failed, retried, or canceled steps can be hidden by a successful final outcome.
SELECT
    j.name AS job_name,
    h.step_id,
    h.step_name,
    CASE h.run_status
        WHEN 0 THEN 'Failed'
        WHEN 2 THEN 'Retry'
        WHEN 3 THEN 'Canceled'
        ELSE CONVERT(varchar(20), h.run_status)
    END AS step_status,
    dbo.agent_datetime(h.run_date, h.run_time) AS run_start_time,
    h.message
FROM dbo.sysjobhistory AS h
JOIN dbo.sysjobs AS j
    ON j.job_id = h.job_id
WHERE h.step_id > 0
  AND h.run_status IN (0, 2, 3)
  AND h.run_date >= CONVERT(int, CONVERT(char(8), DATEADD(day, -7, GETDATE()), 112))
ORDER BY run_start_time DESC, job_name, h.step_id;

SQL Server Agent history is subject to instance-wide and per-job row limits. The query cannot tell you that an expected schedule never existed; compare it with your approved job list. Members of SQL Server Agent roles may see fewer jobs than sysadmin.

Check whether the backups can be restored

Backup jobs can stay green while a new database is missing, a log-backup schedule has gaps, or the latest restore test is too old. Review coverage for every database and confirm that a controlled restore has exercised the recovery path.

Where to look

Native backup and restore history in msdb, the backup product console when a third-party tool owns the process, backup-job output, and the controlled restore-test record.

How to check it

  1. 1.Run the history query and compare full, differential, and log times with the documented RPO for every database, including databases created or restored this week.
  2. 2.Open the backup job or tool output for gaps, destination changes, checksum warnings, unusual size, and unusual duration. A missing scheduled log backup is an RPO miss even when a later log backup succeeds.
  3. 3.Find the latest controlled restore test. Record the chosen recovery point, restore duration, encryption keys or certificates used, CHECKDB result where applicable, and an application or data-access smoke test.

What the result means

A recent timestamp in msdb is useful history, not a restore guarantee. RESTORE VERIFYONLY checks that the backup set is complete and readable, but it does not restore the database or check the internal data structure. Third-party or snapshot backups may also require their own authoritative history.

Latest backup and restore history

Shows the latest native full, differential, and log backup recorded for each database, plus the latest restore recorded under the same destination database name.

WITH LastBackups AS (
    SELECT
        bs.database_name,
        bs.type,
        MAX(bs.backup_finish_date) AS last_backup_finish_date
    FROM msdb.dbo.backupset AS bs
    WHERE bs.type IN ('D', 'I', 'L')
    GROUP BY bs.database_name, bs.type
),
LastRestores AS (
    SELECT
        rh.destination_database_name,
        MAX(rh.restore_date) AS last_restore_start_date
    FROM msdb.dbo.restorehistory AS rh
    WHERE rh.restore_type IN ('D', 'I', 'L')
    GROUP BY rh.destination_database_name
)
SELECT
    d.name AS database_name,
    d.recovery_model_desc,
    d.state_desc,
    MAX(CASE WHEN lb.type = 'D' THEN lb.last_backup_finish_date END) AS last_full_backup,
    MAX(CASE WHEN lb.type = 'I' THEN lb.last_backup_finish_date END) AS last_differential_backup,
    MAX(CASE WHEN lb.type = 'L' THEN lb.last_backup_finish_date END) AS last_log_backup,
    lr.last_restore_start_date
FROM sys.databases AS d
LEFT JOIN LastBackups AS lb
    ON lb.database_name = d.name
LEFT JOIN LastRestores AS lr
    ON lr.destination_database_name = d.name
WHERE d.name <> N'tempdb'
GROUP BY d.name, d.recovery_model_desc, d.state_desc, lr.last_restore_start_date
ORDER BY d.name;

Run in the instance that owns the backup history. Aggressive msdb cleanup can make valid backups disappear from this result. A restore performed on a separate test instance will be recorded on that test instance, so keep a central restore-test record.

The SQL Server backup guide covers log-chain review, backup options, and restore testing in more depth.

Confirm every database had an integrity check

A successful integrity job only shows that its configured work finished. The weekly review checks which databases were included, what CHECKDB options ran, where the output was stored, and whether any database was skipped or reported an error.

Where to look

The integrity job's command table or output files, SQL Server Agent step history, SQL Server error log, and the current list in sys.databases. Custom maintenance frameworks should use their own command log as the main source.

How to check it

  1. 1.List every online database and include master, model, and msdb. Treat tempdb separately because CHECKDB cannot create its normal internal snapshot there.
  2. 2.Match every database to a completed integrity run. Record the command, options, start time, duration, outcome, and stored output. Check whether the job used PHYSICAL_ONLY.
  3. 3.Open every failure or warning. Save the complete output and check related SQL Server, operating-system, and storage errors before planning recovery work.

What the result means

The query below finds likely Agent jobs; it cannot prove per-database coverage when a stored procedure builds the database list dynamically. PHYSICAL_ONLY skips logical checks and needs periodic full CHECKDB coverage. Choose the cadence from database size, recovery needs, workload, and available maintenance capacity.

Locate integrity jobs and recent execution

Finds Agent steps that appear to run DBCC CHECKDB or a common integrity procedure, then shows their most recent recorded run and failures.

USE msdb;

WITH CheckdbSteps AS (
    SELECT
        j.job_id,
        j.name AS job_name,
        j.enabled,
        s.step_id,
        s.step_name,
        s.command
    FROM dbo.sysjobs AS j
    JOIN dbo.sysjobsteps AS s
        ON s.job_id = j.job_id
    WHERE UPPER(s.command) LIKE '%DBCC CHECKDB%'
       OR UPPER(s.command) LIKE '%DATABASEINTEGRITYCHECK%'
       OR UPPER(j.name) LIKE '%CHECKDB%'
       OR UPPER(j.name) LIKE '%INTEGRITY%'
),
StepHistory AS (
    SELECT
        h.job_id,
        h.step_id,
        MAX(dbo.agent_datetime(h.run_date, h.run_time)) AS last_step_run,
        SUM(CASE WHEN h.run_status = 0 THEN 1 ELSE 0 END) AS failures_in_90_days
    FROM dbo.sysjobhistory AS h
    WHERE h.step_id > 0
      AND h.run_date >= CONVERT(int, CONVERT(char(8), DATEADD(day, -90, GETDATE()), 112))
    GROUP BY h.job_id, h.step_id
)
SELECT
    cs.job_name,
    CASE WHEN cs.enabled = 1 THEN 'Enabled' ELSE 'Disabled' END AS job_status,
    cs.step_name,
    CASE
        WHEN UPPER(cs.command) LIKE '%PHYSICAL_ONLY%' THEN 'PHYSICAL_ONLY'
        WHEN UPPER(cs.command) LIKE '%REPAIR_%' THEN 'Repair option present - investigate'
        WHEN UPPER(cs.command) LIKE '%DATABASEINTEGRITYCHECK%' THEN 'DatabaseIntegrityCheck procedure'
        ELSE 'DBCC CHECKDB'
    END AS check_type,
    sh.last_step_run,
    ISNULL(sh.failures_in_90_days, 0) AS failures_in_90_days,
    LEFT(REPLACE(REPLACE(cs.command, CHAR(13), ' '), CHAR(10), ' '), 800) AS command_preview
FROM CheckdbSteps AS cs
LEFT JOIN StepHistory AS sh
    ON sh.job_id = cs.job_id
   AND sh.step_id = cs.step_id
ORDER BY cs.job_name, cs.step_id;

No rows can mean the check runs outside SQL Server Agent or is hidden behind a custom procedure. The result identifies likely jobs; compare the command or command log with the full database inventory. Do not run repair options from a weekly review.

Use the maintenance plan guide when integrity jobs, output retention, or maintenance windows need redesign.

Look for storage pressure before space runs out

Capacity problems usually build over several days or weeks. Compare stored measurements for volumes, data files, transaction logs, tempdb, and backup storage so there is enough time to investigate growth and arrange more capacity.

Where to look

Host or infrastructure monitoring for historical volume free space, SQL Server file metadata, backup storage monitoring, and sys.databases.log_reuse_wait_desc for the current log reuse reason.

How to check it

  1. 1.Run the query and export the result with the week-ending date. Compare volume free space and file sizes with the previous equivalent week.
  2. 2.Review monitoring or file-growth events for repeated data, log, and tempdb autogrowth. Check whether the configured increment is a fixed size or a percentage.
  3. 3.For log growth, read log_reuse_wait_desc and inspect the matching backup, active transaction, availability, replication, or workload history. Estimate when the volume could reach the agreed capacity limit.

What the result means

One current free-space value cannot provide a weekly growth rate. DMV and file metadata need stored snapshots or monitoring history. Autogrow is contingency capacity, not the planned way to size a database. Different log reuse waits need different investigation.

File, volume, and log reuse state

Lists database files, growth settings, hosting-volume capacity, and the current transaction-log reuse wait.

-- File size, growth setting, and free space on the hosting volume.
SELECT
    DB_NAME(mf.database_id) AS database_name,
    mf.name AS logical_file_name,
    mf.type_desc,
    mf.physical_name,
    CONVERT(decimal(18,2), mf.size * 8.0 / 1024.0) AS file_size_mb,
    CASE
        WHEN mf.is_percent_growth = 1 THEN CONCAT(mf.growth, N'%')
        ELSE CONCAT(CONVERT(decimal(18,2), mf.growth * 8.0 / 1024.0), N' MB')
    END AS growth_setting,
    CONVERT(decimal(18,2), vs.available_bytes / 1073741824.0) AS volume_free_gb,
    CONVERT(decimal(18,2), vs.total_bytes / 1073741824.0) AS volume_size_gb
FROM sys.master_files AS mf
CROSS APPLY sys.dm_os_volume_stats(mf.database_id, mf.file_id) AS vs
ORDER BY volume_free_gb, database_name, mf.file_id;

-- The reason SQL Server cannot currently reuse transaction-log space.
SELECT
    name AS database_name,
    recovery_model_desc,
    log_reuse_wait_desc
FROM sys.databases
WHERE database_id > 4
ORDER BY name;

sys.dm_os_volume_stats requires permission to view the relevant server state. The query is a current reading; retain the output or use monitoring data to calculate growth. The same volume can appear once for every file stored on it.

Use the SQL Server sizing guide when the finding needs a proper capacity forecast or storage design change.

Compare query performance with a normal week

Small query regressions can remain hidden until workload increases. A weekly comparison finds queries and plans that used more time or resources during an equivalent business period, while accounting for changes in execution count and rows processed.

Where to look

SSMS under the user database at Query Store → Regressed Queries or Top Resource Consuming Queries, plus Query Store runtime and plan views and the monitoring repository.

How to check it

  1. 1.Confirm Query Store is read-write and retains the full current and comparison periods. Choose two windows with a similar business workload.
  2. 2.Compare average duration, CPU, logical reads, writes, execution count, and row count. Open the plan history when a query changed materially.
  3. 3.Record the database, query ID, plan ID, both time windows, the measure that changed, nearby deployments or maintenance, and the next diagnostic check.

What the result means

A changed average with similar execution count is a stronger regression candidate than a higher weekly total. A different plan can explain the timing, but it does not automatically make plan forcing the right fix. Query Store gaps are themselves monitoring findings.

Compare two Query Store weeks

Run inside one important user database. It returns plans seen during the last 14 days with execution, duration, and logical-read averages for each seven-day period.

-- Run in one important user database with Query Store enabled.
WITH PeriodStats AS (
    SELECT
        q.query_id,
        p.plan_id,
        qt.query_sql_text,
        CASE
            WHEN rsi.start_time >= DATEADD(day, -7, SYSUTCDATETIME()) THEN 'Current week'
            ELSE 'Previous week'
        END AS review_period,
        SUM(rs.count_executions) AS executions,
        SUM(rs.avg_duration * rs.count_executions)
            / NULLIF(SUM(rs.count_executions), 0) AS weighted_avg_duration_us,
        SUM(rs.avg_logical_io_reads * rs.count_executions)
            / NULLIF(SUM(rs.count_executions), 0) AS weighted_avg_reads
    FROM sys.query_store_runtime_stats AS rs
    JOIN sys.query_store_runtime_stats_interval AS rsi
        ON rsi.runtime_stats_interval_id = rs.runtime_stats_interval_id
    JOIN sys.query_store_plan AS p
        ON p.plan_id = rs.plan_id
    JOIN sys.query_store_query AS q
        ON q.query_id = p.query_id
    JOIN sys.query_store_query_text AS qt
        ON qt.query_text_id = q.query_text_id
    WHERE rsi.start_time >= DATEADD(day, -14, SYSUTCDATETIME())
    GROUP BY
        q.query_id,
        p.plan_id,
        qt.query_sql_text,
        CASE WHEN rsi.start_time >= DATEADD(day, -7, SYSUTCDATETIME())
             THEN 'Current week' ELSE 'Previous week' END
)
SELECT TOP (25)
    query_id,
    plan_id,
    LEFT(query_sql_text, 1200) AS query_sql_text,
    MAX(CASE WHEN review_period = 'Previous week' THEN executions END) AS previous_executions,
    MAX(CASE WHEN review_period = 'Current week' THEN executions END) AS current_executions,
    CONVERT(decimal(18,2), MAX(CASE WHEN review_period = 'Previous week' THEN weighted_avg_duration_us END) / 1000.0) AS previous_avg_ms,
    CONVERT(decimal(18,2), MAX(CASE WHEN review_period = 'Current week' THEN weighted_avg_duration_us END) / 1000.0) AS current_avg_ms,
    CONVERT(decimal(18,2), MAX(CASE WHEN review_period = 'Previous week' THEN weighted_avg_reads END)) AS previous_avg_reads,
    CONVERT(decimal(18,2), MAX(CASE WHEN review_period = 'Current week' THEN weighted_avg_reads END)) AS current_avg_reads
FROM PeriodStats
GROUP BY query_id, plan_id, query_sql_text
HAVING MAX(CASE WHEN review_period = 'Current week' THEN executions END) IS NOT NULL
ORDER BY current_avg_ms DESC, current_avg_reads DESC;

Query Store views are database-scoped and need Query Store to retain both periods. The query uses UTC Query Store interval times; align the periods with the business workload and local reporting convention. Review plan XML, parameters, rows, and nearby changes before recommending a production change.

The SQL Server monitoring guide covers the collection needed when Query Store or performance history is missing.

Find recurring blocking, deadlocks, and waits

Blocking and deadlocks often finish before anyone opens SSMS. Review saved captures across the week to find the same head blocker, application operation, database object, deadlock shape, or wait pattern appearing repeatedly.

Where to look

The monitoring repository, blocked-process reports, long-transaction captures, the built-in system_health session for recent deadlock XML, and a dedicated Extended Events session when longer retention is needed.

How to check it

  1. 1.Filter captures to the seven-day window and group blocking by head blocker, application, database, object, and time of day. Keep the full chain and transaction age.
  2. 2.Open every deadlock graph. Compare processes, resources, statements, isolation levels, and application operations instead of reviewing only the victim.
  3. 3.Compare wait deltas for meaningful workload intervals, excluding expected idle waits. Link the repeated pattern to the next query, transaction, indexing, or application investigation.

What the result means

Repeated shape matters more than one short wait. The same application operation or object across several captures gives the investigation a useful starting point. A weekly historical result does not justify killing a current session or changing isolation settings.

Use the wait, blocking, and deadlock guides for the actual diagnosis and safe live checks.

Read the logs and confirm alerts arrived

Repeated warnings, short service restarts, and notification failures are easy to miss when each day is reviewed separately. Read the full log window and confirm that important events reached the mailbox, ticket queue, or monitoring route people use.

Where to look

SSMS under Management → SQL Server Logs and SQL Server Agent → Error Logs, archived log files, Windows Event Viewer or the Linux journal, Database Mail history, and the external monitoring event timeline.

How to check it

  1. 1.Search the current and archived SQL Server logs for unexpected starts, recovery messages, stack dumps, I/O errors, database state changes, failed logins where relevant, and recurring warnings. Match the time with host logs.
  2. 2.Review Agent and Database Mail logs for failed notifications. Pick an important event from the week and confirm the final recipient received it.
  3. 3.When no suitable event fired, run an approved Database Mail or monitoring delivery test. Record the originating rule, recipient, delivery state, and test time.

What the result means

A successful Database Mail test checks the mail path. It does not prove that Agent notifications, severity alerts, or external rules are configured correctly. An important event with no delivered message is a separate alerting failure.

Check HA data movement and failover dependencies

A healthy HA dashboard now does not describe the whole week. Review data-movement history, queue growth, suspensions, role changes, and the jobs, logins, paths, and backup logic needed on the server that would take over.

Where to look

Availability Group DMVs and dashboard, log shipping or replication monitors, Agent history on every host, backup history, login and job inventories, and the latest controlled failover record.

How to check it

  1. 1.Run the query on each replica. Check connection, synchronization, suspension, send and redo queues, and preferred backup status against the role and recovery target.
  2. 2.For log shipping or replication, inspect the backup, copy, restore, reader, distribution, merge, or snapshot job chain and its recorded latency.
  3. 3.Compare jobs, owners, credentials, paths, and relevant logins across failover partners. Confirm backup jobs use preferred-replica logic and that backups still exist independently of the secondary.

What the result means

There is no useful universal queue threshold. Judge queue size and catch-up time against workload and recovery targets. An asynchronous secondary can normally report SYNCHRONIZING. Agent jobs and logins are instance objects and do not move with an availability database.

Availability Group state and backup preference

Shows replica and database health, suspension, queue sizes, and whether the local replica is preferred for backup. Run on every replica for a complete view.

SELECT
    ag.name AS availability_group_name,
    ar.replica_server_name,
    ars.role_desc,
    ars.connected_state_desc,
    ars.synchronization_health_desc AS replica_health,
    DB_NAME(drs.database_id) AS database_name,
    drs.synchronization_state_desc,
    drs.synchronization_health_desc AS database_health,
    drs.is_suspended,
    drs.suspend_reason_desc,
    drs.log_send_queue_size,
    drs.redo_queue_size,
    sys.fn_hadr_backup_is_preferred_replica(DB_NAME(drs.database_id))
        AS is_preferred_backup_replica
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
LEFT JOIN sys.dm_hadr_database_replica_states AS drs
    ON drs.replica_id = ar.replica_id
ORDER BY ag.name, ar.replica_server_name, database_name;

Availability Group DMV visibility differs between the primary and secondary replicas. VIEW SERVER STATE or the version-appropriate server performance permission is required for full DMV output. Queue values are current readings; use monitoring history to review the full week.

Use the SQL Server failover guide to prepare a controlled failover test with application validation and rollback.

Match new problems to recent changes

New failures and performance changes often appear close to a deployment, patch, permission update, infrastructure change, or temporary workaround. Put those events on one timeline to give the next investigation a sensible starting point.

Where to look

Change tickets, deployment pipelines, source-control releases, SQL Audit or approved audit output, configuration repositories, patch records, and the temporary-change register.

How to check it

  1. 1.List every change that touched the SQL Server host, instance, database, application connection, storage, network, or monitoring route during the review window.
  2. 2.Match the time and affected systems with new job failures, backup gaps, performance regressions, alerts, or HA events. Record the validation that ran after each change.
  3. 3.Find temporary work: disabled jobs, forced plans, trace flags, exclusions, emergency settings, and temporary permissions. Confirm each has an owner, review date, and removal or acceptance decision.

What the result means

SQL Server cannot reliably reconstruct every past configuration, deployment, or permission change after the event. Missing history is a collection gap. Record what must be audited next time instead of guessing from the current configuration.

Use the SQL Server patching guide when the recent work needs a controlled validation or rollback plan.

Leave every finding with an owner

Findings without a clear next step tend to return in the following review. Turn each exception into a small work item that names the affected system, current impact, owner, due date, and the first action to take.

Where to look

The service desk, engineering backlog, change system, or another shared record that the owner and the next weekly reviewer can open.

How to check it

  1. 1.Group duplicate symptoms into one finding, but keep every affected instance or database listed.
  2. 2.Put current recovery, integrity, availability, and production risks first. Choose the next diagnostic or scheduling action, not a guessed fix.
  3. 3.Name one accountable owner role and one due date. If work depends on a test system, vendor response, approval, or maintenance window, make that dependency the next dated action.

What the result means

A useful action is specific enough to move before the next review. “Investigate performance” is too broad. “Compare Query Store plans 918 and 921 for the weekday order search by Friday” gives the owner a starting point and a finish condition.

Copyable weekly review record

Week ending:
SQL Server instances reviewed:
Status: OK / Follow up / Urgent

Failed or slow jobs:
Backup or restore concerns:
CHECKDB gaps or errors:
Capacity and file-growth concerns:
Performance regressions:
Blocking or deadlocks:
Log or alert problems:
HA/replication concerns:
Recent changes needing follow-up:

Next action | Owner | Due date

Keep production changes out of the review

Investigation and change control are separate jobs. The weekly review can recommend work, but each production change still needs testing, approval, a maintenance window where required, monitoring, and a rollback plan. This is especially important when the proposed fix changes query plans, files, server configuration, or failover behaviour.

Weekly does not mean rebuild every index, shrink every file, or install every patch. Base index maintenance on measured workload and use. Plan SQL Server patching with compatibility checks, working backups, a tested rollout, and rollback. Give every approved change success criteria and post-change checks.

SQL Server weekly review questions

Does every SQL Server need the same checklist?

Use the same ten subjects, then define the expected result for each system. A small reporting instance may have different backup schedules, recovery targets, HA checks, and escalation routes from a revenue-critical transactional system.

Should every weekly check be manual?

Automate the collection and immediate failure alerts. Keep the human review for comparing periods, interpreting exceptions, noticing missing notifications, and deciding what happens next. If the weekly meeting is spent collecting basic job and backup history, that is the first part to automate.

How long should the weekly SQL Server review take?

It depends on the estate and the number of exceptions. A healthy week should be quick when central reports collect the results. The review takes longer when a restore failed, capacity changed sharply, or a recurring performance problem needs to be handed into a proper investigation.

Need help automating these SQL Server checks?

If this review still depends on opening every server and copying results by hand, I can set up the collection, reports, and alerts. A SQL Server health audit shows which checks already run, where the gaps are, and what is worth automating first. You can also request a quote for the review.

Next step

Use the SQL Server stability review guide when the same performance, capacity, maintenance, or ownership problems keep returning.

Use the SQL Server environment assessment guide when you need to map the wider estate, dependencies, ownership, and readiness for planned work.

Microsoft sources