SQL Server health review

Contoso Group (sample data)

Prepared by BPS

2servers reviewed

4urgent problems to talk through

24problems to plan

Use the right and left arrow keys to move between pages. Press G for a list of pages, N for presenter notes, F for full screen.

The review in one picture

6 urgent, 43 to plan, across 2 servers

Urgent means act soon. To plan means schedule it. Worth knowing is for awareness.

What good looks like

No urgent items. Anything to plan is on a dated list with an owner.

Suggested next steps

Start with the urgent items; they are listed server by server on the pages that follow.
Agree owners and dates for the items to plan.

Server by server, area by area

Where the problems are

Each box shows how many findings are in that area for that server. Red boxes show the number of urgent ones; amber boxes have nothing urgent and show how many to plan; grey boxes show items for awareness only; a green tick means nothing found. Most urgent items: sqlapp01.

What good looks like

Every box is a green tick, or amber at most, with nothing urgent.

Suggested next steps

Work down the red boxes first, starting with the server that has the most urgent items.
Open the page for each area to see what was found and what to do.

Progress

0 fixed or gone, 0 new since the last review

Server	Last run	Change	New	Fixed or gone
sqlapp01	2026-10-23 15:00	3→3 urgent 20→20 to plan	Nothing new	Nothing fixed
sqlprd01	2026-10-23 14:40	1→1 urgent 22→22 to plan	Nothing new	Nothing fixed

Good news first

What is working well

Security	The sa login is disabled. (every server) xp_cmdshell is off. (every server)
Operations and monitoring	Backup compression is on by default. (every server) The scheduled-job service (SQL Server Agent) is running. (every server)

At a glance

What is not in good shape

sqlapp01	SQL Server 2019: extended support until Jan 2030	4 urgent21 to plan
sqlprd01	SQL Server 2019: extended support until Jan 2030	2 urgent22 to plan

What good looks like

Each server shows no urgent items and a short list to plan.

Suggested next steps

Start with the server that has the most urgent items.
Go through the pages that follow for the detail on each item.

How the servers are connected

2 servers, 2 availability groups

Each row is an availability group: one primary copy of the data (P) and secondary copies (S) kept in step on the other servers. This page shows how the servers are connected; the problems found are on the pages that follow.

What good looks like

Every availability group has a primary and healthy secondary copies, on more than one network or site.

Suggested next steps

Confirm this layout is what the business intends.
Check that each group has a copy away from the primary’s site.

The big three

Memory, disk space and processor

Red = needs attention now, amber = watch, green = fine. Memory pressure is judged on page life expectancy as well as how full the memory is.

What good looks like

Memory is not under pressure, every drive has at least 20% free, and processors are not constantly busy.

Suggested next steps

Free space or add disk on any drive that is nearly full.
Check the memory setting on servers that are under memory pressure.

How the servers are set up

Every server runs Enterprise Edition

Evidence

sqlapp01	Enterprise (core licensing)	15.0.4500.2	8 processors	47 GB set aside for SQL Server
sqlprd01	Enterprise (core licensing)	15.0.4500.2	16 processors	109 GB set aside for SQL Server

What this tells us

Availability groups need it. appag keeps 6 copies (the basic group on Standard allows only 2); appag lets the secondary copies be read (not possible on Standard); finag keeps 4 copies (the basic group on Standard allows only 2); finag lets the secondary copies be read (not possible on Standard). Every server that holds a copy has to be Enterprise.
Server size is not the reason. Every server is within what Standard allows (24 processors and 128 GB of memory). The largest has 16 processors and 109 GB set aside for SQL Server.
Other features: compression, partitioning, encryption and the like were not checked in this run. A new check lists them on the next run.

Why it matters

Enterprise licences cost several times more per core than Standard. It is worth confirming that every server needs the extra features it is paying for.

Suggested next steps

Run the audit again with the new feature check, so each server’s Enterprise features are listed.
For each server, confirm it still needs these features. A server that only holds a standby copy may not need Enterprise.
Check how standby and read-only copies are licensed under your Microsoft agreement.

What good looks like

Every server runs the edition it needs.

How the servers are set up

Enterprise is needed on every server

Based on the availability group design only. The feature check (compression, partitioning, encryption and more) was not part of this run.

What good looks like

Each Enterprise licence is used for a feature the business needs.

Suggested next steps

Ask the owners of each server whether the features shown are still needed.
Check how standby and read-only copies are licensed.

How the servers are set up

Availability group appag

Evidence

6 copies of AppDb; primary: sqlprd01

Server	Role	Updates	Failover	Readable	Network
sqlprd01	Primary	–	Manual	Yes	10.50.25.0/24
sqlapp01	Secondary	Does not wait (can lag)	Manual	Yes	10.50.25.0/24
sqlapp02 (not in this review)	Secondary	Does not wait (can lag)	Manual	Yes	10.50.25.0/24
sqlapp03 (not in this review)	Secondary	Does not wait (can lag)	Manual	Yes	10.50.25.0/24
sqldw01 (not in this review)	Secondary	Does not wait (can lag)	Manual	Yes	10.50.18.0/24
sqlrpt01 (not in this review)	Secondary	Does not wait (can lag)	Manual	Yes	10.50.25.0/24

What it means

Every secondary copy is updated without waiting, so it can be a little behind. If the primary failed suddenly, the most recent changes could be lost.
Failover is manual. Nothing moves the primary role by itself; someone has to do it, so the service stays down until they do.
The secondary copies can be read. Reports and other read-only work can run there and take load off the primary.
The copies sit on 2 networks (10.50.18.0/24, 10.50.25.0/24), which suggests a copy at another site for disaster recovery.
It runs on the Windows cluster ProdCluster with 6 servers and no witness.

Questions to put to the team

Is manual failover intended, and who does it, and how fast?
How much recent data can the business afford to lose if the primary fails?
Include the servers that were not in this review next time.
Has the copy at the other site been tested by a real failover?

What good looks like

All copies are healthy, keeping up, and each is placed where the design needs it.

How the servers are set up

Availability group finag

Evidence

4 copies of FinanceDb; primary: sqlapp01

Server	Role	Updates	Failover	Readable	Network
sqlapp01	Secondary	Does not wait (can lag)	Manual	Yes	10.50.25.0/24
sqlapp03 (not in this review)	Secondary	Does not wait (can lag)	Manual	Yes	10.50.25.0/24
sqlfin01 (not in this review)	Secondary	Waits for the copy	Manual	Yes
sqlrpt01 (not in this review)	Secondary	Does not wait (can lag)	Manual	Yes	10.50.25.0/24

What it means

At least one secondary waits for the primary, so nothing it has confirmed is lost if the primary fails.
Failover is manual. Nothing moves the primary role by itself; someone has to do it, so the service stays down until they do.
The secondary copies can be read. Reports and other read-only work can run there and take load off the primary.
The group has no cluster behind it, so there is no automatic failover and no cluster to keep it running.

Questions to put to the team

Is manual failover intended, and who does it, and how fast?
Include the servers that were not in this review next time.
Which applications read from the copies, and which connect to the primary?

What good looks like

All copies are healthy, keeping up, and each is placed where the design needs it.

How the servers are set up

1 (50%) availability groups need attention · 2 servers

The whole high-availability picture on one page, before the detail. Each tile is judged on this audit’s data: green is fine, amber is worth planning, red needs action soon, grey was not reported. The next pages explain each tile.

What good looks like

Every group is healthy, and each copy is in the state the design intends.

Suggested next steps

Fix the groups marked as needing attention first.
Review manual versus automatic failover against what the business expects.

How the servers are set up

All 9 secondary copies are healthy and keeping up

Taken when the audit ran. Solid arrow = the primary waits for the copy; dashed = it does not, so the copy can fall behind. Queues are the data still waiting to be sent to, or applied on, the copy. Red = unhealthy, suspended or over a minute behind.

What good looks like

Secondary copies keep up, with seconds or less of delay and nothing waiting to be sent.

Suggested next steps

Investigate any copy that is behind or unhealthy.
Decide whether copies that can fall behind are acceptable for recovery.

How the servers are set up

1 (100%) clusters have no tie-breaker

Every server in the cluster holds a vote and the cluster stays up only while more than half of all votes can talk to each other. A witness is an extra vote that avoids a tie.

What good looks like

Every cluster has a tie-breaker, so it survives losing a server or a network split.

Suggested next steps

Add a tie-breaker (witness) to clusters that have none.
Re-check the vote count after any server is added or removed.

Data protection

3 (6%) databases need backup attention

One bar per server; every database is a share of the bar. Red databases have no full backup in the last 7 days, no log backup where one is needed, or log backups thrown away.

What good looks like

Every database has a full backup in the last 7 days, and log backups wherever the database needs them.

Suggested next steps

Fix the databases shown in red first.
Run a test restore of at least one database from each server.

Storage

7 busy database files respond slowly

One square per busy database file, worst first. Response time since the last restart; under 20 ms is good for data files.

What good looks like

Busy database files respond in under 20 ms.

Suggested next steps

Ask the storage team to look at the slow volumes.
Move the busiest files to faster storage if the slowness continues.

Capacity

2,460 GB of data in 41 databases

Each database is counted once, even where copies sit on several servers (availability groups). Disk used on each server, copies included: sqlapp01 1,561 GB, sqlprd01 1,453 GB.

What good looks like

Data growth is understood, and there is room for at least a year of growth.

Suggested next steps

Check free space against expected growth for the largest databases.
Archive or remove data nobody needs.

Indexes

Indexes to add

Database	Table (columns)	Why
AppDb	[AppDb].[dbo].[Obj00527]	The optimizer asked for it 14,174 times; estimated 47% faster
AppDb	[AppDb].[dbo].[Obj00616_obj00507_usage]	The optimizer asked for it 242,802 times; estimated 100% faster
AppDb	[AppDb].[dbo].[Obj00793]	The optimizer asked for it 584,112 times; estimated 22% faster
AppDb	[AppDb].[dbo].[obj00794]	The optimizer asked for it 79,793 times; estimated 76% faster
AppDb	[AppDb].[dbo].[Obj00793]	The optimizer asked for it 457,541 times; estimated 19% faster
AppDb	[AppDb].[dbo].[Obj00793]	The optimizer asked for it 457,541 times; estimated 18% faster
AppDb	[AppDb].[dbo].[Obj00793]	The optimizer asked for it 457,541 times; estimated 18% faster
AppDb	[AppDb].[dbo].[Obj00793]	The optimizer asked for it 457,541 times; estimated 17% faster
AppDb	[AppDb].[dbo].[Obj00795]	The optimizer asked for it 547,145 times; estimated 14% faster
AppDb	[AppDb].[dbo].[obj00512]	The optimizer asked for it 32,058 times; estimated 48% faster

10 suggested. The report holds each one with a script to copy.

What good looks like

The queries that matter have indexes that support them.

Suggested next steps

Review the suggestions with the application owners.
Test each new index on a copy before adding it to production.

Indexes

1 (100%) index maintenance jobs are not running

Server	Job	State
sqlprd01	IndexOptimize - USER_DATABASES	No schedule, not running

Statistics age on the larger databases:

sqlprd01, AppDb_datastore: 755 (97%) statistics are over 90 days old (97%)
sqlapp01, dev_apps: 1,658 (87%) statistics are over 90 days old (87%)
sqlapp01, contoso_apps: 971 (83%) statistics are over 90 days old (83%)
sqlprd01, Obj00007_440: 2,546 (66%) statistics are over 90 days old (66%)
sqlapp01, AppDb: 5,011 (39%) statistics are over 90 days old (39%)

A job with no schedule may be started by something else; this check only sees Agent schedules and the last 7 days of runs.

What good looks like

Index maintenance runs on a schedule and succeeds every time.

Suggested next steps

Enable or schedule any maintenance job that is not running.
Update statistics that are old on the larger databases.

UrgentCapacity and storage · 2 servers

Disk drives running out of space

Evidence

sqlapp01	Drive E:\ is nearly full (9.4% free)
sqlprd01	Drive H:\ is getting full (14.5% free)

Why it matters

When a drive fills, databases stop accepting changes and applications fail.

What good looks like

At least 20% free on every drive (urgent below 10%).

Suggested next steps

Find what is using the space and clear what is safe to clear.
Archive or move old data, or ask for more space.
Set an alert at 20% free.

UrgentData protection · 2 servers

Transaction log backups are being thrown away

Evidence

sqlapp01	FinanceDb – SQL Server's own records show the transaction log of FinanceDb was “ba AppDb – SQL Server's own records show the transaction log of AppDb was “backed
sqlprd01	AppDb: log backups were sent to NUL

Why it matters

These databases can only be restored to their last full backup, not to a recent moment, and the log can grow without limit.

What good looks like

Log backups go to real backup files every 15 to 60 minutes for every database in FULL recovery.

Suggested next steps

Find the job or script that sends the log backup to NUL.
Point it at a real backup folder or share.
Take a new full backup to restart the chain, then confirm log backups appear.

UrgentData protection · 1 server

Backup jobs that fail regularly

Evidence

sqlprd01

Backup job “Job00058.job00124_bk” fails often (60.1% success)
Backup job “Job00058.AppDb_backup” fails often (90.0% success)

Why it matters

A backup that fails quietly leaves less protection than anyone thinks.

What good looks like

Backup jobs succeed every time, and any failure is looked at the same day.

Suggested next steps

Open the job history and find the failing step.
Fix the cause (space, permissions or path).
Re-run it, confirm it succeeds, and add an email on failure.

UrgentCapacity and storage · 1 server

Slow disk response

Evidence

sqlapp01

4 database file(s) have slow disk response

Why it matters

Slow storage makes every application that uses these databases slower.

What good looks like

Average read and write under 20 ms for data files, and under 10 ms for log files.

Suggested next steps

Find the busiest files and the drive they are on.
Ask the storage team to check for contention or a configuration problem.
Spread the busy files across drives or move them to faster storage.

PlanAvailability · 2 servers

Cluster could split in two with no tie-breaker

Evidence

sqlapp01	Cluster has 6 voting nodes and no witness
sqlprd01	Cluster has 6 voting nodes and no witness

Why it matters

If the network between the servers is cut, neither side may know it should stay up.

What good looks like

A witness (file share, disk or cloud) so the cluster can always reach a majority.

Suggested next steps

Choose a witness type: a file share or a cloud witness.
Add it to the cluster.
Check the cluster now shows the witness and a healthy quorum.

PlanSecurity · 2 servers

Database users that could map to the wrong login after a restore

Evidence

sqlapp01	14 database user(s) share a name with a different server login
sqlprd01	1 database user(s) share a name with a different server login

Why it matters

Someone could silently get another person’s access.

What good looks like

A database user and the server login with the same name are the same identity.

Suggested next steps

List the mismatched users.
Re-link each user to the right login, or remove it.
Check again after the next restore.

PlanData protection · 2 servers

Databases never checked for corruption

Evidence

sqlapp01	10 user database(s) have no successful consistency check (CHECKDB) in the last 14 days
sqlprd01	8 user database(s) have no successful consistency check (CHECKDB) in the last 14 days

Why it matters

Corruption found late may already be in every backup.

What good looks like

A successful consistency check (CHECKDB) at least weekly for every database.

Suggested next steps

Schedule a weekly consistency check (CHECKDB).
Run it now on the databases listed.
Review the results and alert on any error.

PlanSecurity · 2 servers

Linked servers that sign in with a stored or powerful login

Evidence

sqlapp01	19 linked server mapping(s) need review
sqlprd01	12 linked server mapping(s) need review

Why it matters

A weak link to another server can expose both servers.

What good looks like

Each linked server uses the caller’s own identity or a minimal-rights account, and never sa.

Suggested next steps

List each linked server and who or what uses it.
Switch to the caller’s own identity or an account with minimal rights.
Remove the ones that are no longer used.

PlanData protection · 2 servers

Long gaps between backups

Evidence

sqlapp01	2 database(s) have a worst-case data loss window of more than 24 hours
sqlprd01	3 database(s) have a worst-case data loss window of more than 24 hours

Why it matters

After a failure, up to this much recent work could be lost.

What good looks like

No gap between backups longer than the agreed data-loss window (for example 1 hour).

Suggested next steps

Agree with the business how much recent work it can afford to lose.
Set the backup frequency to match.
Confirm the gaps in the backup history are gone.

PlanSecurity · 2 servers

Many accounts with full administrator rights

Evidence

sqlapp01	14 enabled logins have full administrator (sysadmin) rights
sqlprd01	18 enabled logins have full administrator (sysadmin) rights

Why it matters

Every such account can read, change or delete everything.

What good looks like

Only the few accounts that truly need full control, named people or managed service accounts.

Suggested next steps

List every member of the administrator role.
Remove the accounts that do not need it.
Use named accounts, not shared ones.

PlanOperations and monitoring · 2 servers

Nobody is warned when SQL Server reports a serious error

Evidence

sqlapp01	No SQL Agent alerts for corruption (errors 823, 824, 825) No SQL Agent alerts for severity 19-25 errors
sqlprd01	No SQL Agent alerts for corruption (errors 823, 824, 825) No SQL Agent alerts for severity 19-25 errors

Why it matters

Serious problems can go unnoticed until users complain.

What good looks like

Alerts for severity 19 to 25 and errors 823, 824 and 825 reach an operator who reads them.

Suggested next steps

Create an operator with a mailbox someone reads.
Create alerts for severity 19 to 25 and errors 823, 824 and 825.
Send a test alert.

PlanSecurity · 2 servers

Optional server features switched on that widen the attack surface

Evidence

sqlapp01	2 server feature(s) widen the attack surface
sqlprd01	4 server feature(s) widen the attack surface

Why it matters

Each one is another way in if the server is attacked.

What good looks like

Features such as xp_cmdshell, OLE Automation, ad hoc queries and cross-database chaining are off unless an application needs them.

Suggested next steps

Find out which applications use each feature.
Switch off the ones nothing needs.
Write down the ones kept, and why.

PlanPerformance · 2 servers

Out-of-date query statistics

Evidence

sqlapp01	10,055 (22%) statistics are older than 90 days; 100 have over 100,000 changes since the last update
sqlprd01	9,464 (43%) statistics are older than 90 days; 68 have over 100,000 changes since the last update

Why it matters

Queries can pick slow plans.

What good looks like

Fewer than a quarter of the statistics older than 90 days, refreshed by a regular job.

Suggested next steps

Check whether a statistics or index maintenance job exists.
Add a weekly statistics update if not.
Check the age again after it has run.

PlanSecurity · 2 servers

Permissions granted to every user of a database (the public role)

Evidence

sqlapp01	Permissions are granted to the public role in 15 database(s)
sqlprd01	Permissions are granted to the public role in 3 database(s)

Why it matters

Everyone with access to the database gets them.

What good looks like

No object or column permissions are granted to public; they go to named roles.

Suggested next steps

List what is granted to public.
Create named roles for the real need and grant the access there.
Revoke from public and test the applications.

PlanSecurity · 2 servers

SQL logins that ignore the password policy

Evidence

sqlapp01	31 SQL login(s) do not enforce the password policy
sqlprd01	25 SQL login(s) do not enforce the password policy

Why it matters

Their passwords never expire and can be weak.

What good looks like

Password policy is enforced for every SQL login.

Suggested next steps

List the SQL logins that skip the policy.
Turn the policy on in a quiet period and check the applications that use them.
Move service logins to managed accounts where possible.

PlanOperations and monitoring · 2 servers

Scheduled jobs that fail without telling anyone

Evidence

sqlapp01	9 (31%) enabled Agent jobs send no email at all
sqlprd01	22 (25%) enabled Agent jobs send no email at all

Why it matters

Failures can go unnoticed for days.

What good looks like

Every important job notifies an operator when it fails.

Suggested next steps

List the jobs that have no failure notice.
Assign an operator to be told when each fails.
Test with one job.

PlanCapacity and storage · 2 servers

Very large, mostly empty transaction logs

Evidence

sqlapp01	FinanceDb – Log size 410 GB, 100% free, against 396 GB of data AppDb – Log size 231 GB, 100% free, against 306 GB of data
sqlprd01	AppDb: the transaction log is 231 GB and almost empty

Why it matters

They hold disk space that other databases may need.

What good looks like

Each log is close to its normal working size.

Suggested next steps

Find out why the log grew (often a one-off job).
Shrink it only after the cause is fixed.
Set a sensible fixed size.

PlanSecurity · 2 servers

Weak or expired encryption keys and certificates

Evidence

sqlapp01	2 encryption key or certificate problem(s)
sqlprd01	2 encryption key or certificate problem(s)

Why it matters

Encrypted data may not be as protected as assumed.

What good looks like

AES keys, certificate keys of 2048 bits or more, and nothing expired.

Suggested next steps

List the weak or expired keys and certificates.
Replace them with AES keys and certificates of 2048 bits or more.
Back up the new keys safely and set renewal reminders.

PlanSecurity · 1 server

Accounts with very powerful permissions in databases

Evidence

sqlapp01

8 high-impact permission grant(s) to users or roles

Why it matters

Mistakes or misuse by those accounts have a large effect.

What good looks like

Powerful permissions (CONTROL, ALTER, IMPERSONATE) are held only by named administrators.

Suggested next steps

List the accounts that hold them.
Replace each with the narrowest permission that works.
Review the list every year.

PlanOperations and monitoring · 1 server

Database Mail is reporting errors

Evidence

sqlprd01

Database Mail reported 10 error(s) in the last 7 days

Why it matters

Alert and job emails may not be arriving.

What good looks like

The mail profile works and shows no errors.

Suggested next steps

Open the Database Mail log to read the error.
Fix the mail server address or sign-in.
Send a test email.

PlanSecurity · 1 server

Database settings that bypass normal security checks

Evidence

sqlprd01

Trustworthy is ON (only msdb should have it) in 1 database(s)

Why it matters

They let code in one database act with the rights of another.

What good looks like

Trustworthy is off except in msdb, and cross-database chaining is off for user databases.

Suggested next steps

Find out whether any application needs them (usually none do).
Switch them off and test.
Keep only where a reason is written down.

PlanOperations and monitoring · 1 server

Database text-comparison settings differ from the server

Evidence

sqlapp01

Collation differs from the server and tempdb; string comparisons with temp tables can fail (3 database(s))

Why it matters

Queries that join to temporary data can fail.

What good looks like

User databases use the same collation as the server.

Suggested next steps

List the databases that differ and check whether they use temporary tables.
Change the collation only where problems appear.
Test on a copy first.

PlanPerformance · 1 server

Query Store has stopped recording

Evidence

sqlapp01

Query Store is read-only in 2 database(s)

Why it matters

No history is kept to explain slow queries.

What good looks like

Query Store is on and read-write for the important databases.

Suggested next steps

Check why it is read-only (usually it is full).
Raise its size or clear old data.
Set it back to read-write.

PlanAvailability · 1 server

Repeated connection time-outs between servers in the group

Evidence

sqlprd01

Connections to 3 secondary replica(s) time out repeatedly (15 times in the log)

Why it matters

The standby copies can fall behind or disconnect.

What good looks like

No repeated time-outs between the servers in the group.

Suggested next steps

Compare the error-log times with network, VM snapshot and patching events.
Check the firewall and the group’s port between the servers.
Raise the session time-out only if the network is stable.

PlanOperations and monitoring · 1 server

Scheduled jobs that failed this week

Evidence

sqlprd01

4 Agent job(s) failed in the last 7 days

Why it matters

Work they should be doing is not happening.

What good looks like

Every scheduled job succeeds, and any failure is looked at the same day.

Suggested next steps

Open each failed job’s history to find the failing step.
Fix the cause, or retire the job if it is no longer needed.
Add an email to an operator on failure.

PlanOperations and monitoring · 1 server

Scheduled jobs that often fail

Evidence

sqlprd01

6 other Agent job(s) succeed less than 95% of the time

Why it matters

They need attention before they stop working altogether.

What good looks like

Every scheduled job succeeds, and any failure is looked at the same day.

Suggested next steps

Open each job’s history to find the failing step.
Fix the cause, or retire the job if it is no longer needed.
Add an email to an operator on failure.

PlanPerformance · 1 server

The temporary database (tempdb) is not set up the recommended way

Evidence

sqlapp01

tempdb configuration can be improved

Why it matters

It can slow every busy application.

What good looks like

Equal-size data files (up to 8, about one per processor), fixed growth steps, and not on the C: drive.

Suggested next steps

Add data files, equal in size, up to one per processor (maximum 8).
Set a fixed growth size and move the files off the C: drive.
Restart in a maintenance window and check again.

PlanCapacity and storage · 1 server

Transaction logs with far too many internal segments

Evidence

sqlapp01

1 transaction log(s) have a very high virtual log file count

Why it matters

Startup, restore and log backup are slower than they should be.

What good looks like

Under 1,000 virtual log files per log (under 500 is ideal).

Suggested next steps

Check the segment count of each log.
Shrink the log once and regrow it in a few large steps.
Set a fixed growth size so it does not repeat.

The way forward

About 120 hours of effort, urgent items first

Hours per kind of problem, taken from the remediation estimate. Bars are laid end to end in the order the work would be done; the real plan can run items in parallel.

What good looks like

The urgent items are done first, with an owner and a date for each.

Suggested next steps

Agree the order, owners and dates.
Plan the work around business calendar peaks.

Results

Results: 0 measures improved

6 → 6Urgent findings

302 → 302Differences between replicas

Before: 2026-10-23_143259 (2026-10-23 14:40). After: the newest run (2026-10-23 15:00). A measure is improved only when the second run no longer shows the problem; it is not a prediction. Measures only one of the two runs could take are left out.

Results

Availability: 0 (0%) measures improved

Same measures, taken from the second run.

Results

What was done about each recommendation

Action	Where	Status
Add	[AppDb].[dbo].[Obj00527]	Still requested
Add	[AppDb].[dbo].[Obj00616_obj00507_usage]	Still requested
Add	[AppDb].[dbo].[Obj00793]	Still requested
Add	[AppDb].[dbo].[obj00794]	Still requested
Add	[AppDb].[dbo].[Obj00793]	Still requested
Add	[AppDb].[dbo].[Obj00793]	Still requested
Add	[AppDb].[dbo].[Obj00793]	Still requested
Add	[AppDb].[dbo].[Obj00793]	Still requested
Add	[AppDb].[dbo].[Obj00795]	Still requested
Add	[AppDb].[dbo].[obj00512]	Still requested

The plan

120 hours to fix what was found

The quote

Work	Items	BPS effort
Urgent items	4	27 hours
Items to plan	24	93 hours
Total	28	120 hours

How we show the improvement

The main report is the before: it records where every server stands today.
When the work is done we run the same review again. The report then shows the after next to the before for each measure, so every improvement can be seen and checked.
Anything not yet fixed stays visible, so nothing is lost between rounds of work.

Suggested next steps

Agree the scope and the order of the work, urgent items first.
Agree owners and maintenance windows for each server.
Run the review again when the work is finished, to confirm the results.