Server Overview

Server operations cockpit

Pick a server and read the current story: what happened, what is happening, what happens next, and exactly what to do first.

Critical 2026-09-02 10:17
Critical5
Action0
Watch0
Stable0
Open actions53
Runtime events10063
Telemetry gaps0
Growth0.0 GB
Operational impact 6 / 100 High exposure ยท evidence coverage 100%
Recovery readiness Backup chains, restore confidence and failed maintenance are folded into each server's actions.
0
Capacity protection Low disk, database growth and projected pressure are visible before they become write failures.
0
Service reliability Failed jobs, runtime events, deadlocks, blocking and long-running queries are treated as connected reliability evidence.
10116
Data confidence Telemetry gaps are counted as risk so empty panels are not mistaken for healthy systems.
0
Action Center Backup Readiness Data Quality
Critical

SERVER 2

TESTSRV_2.DBNEXIA.COM / Test / SQL Server / Last seen 2026-09-02 10:15
Health0
Pressure100
TrendDeteriorating
DirectionRising risk
Best advice

P1 Workload: Trace blockers/deadlocks to statement, index, and transaction order. This is first because concurrency incidents usually repeat under the same application path until the blocking pattern is removed. Pattern: Repeated blocking or deadlocks indicate a transaction, query, or indexing pattern.

Dashboard Report
What happened

In the selected window, 3181 log/runtime events were recorded, latest at 2026-09-02 10:14; 10 deadlocks and 2 blocking events appeared; 1 long running requests exceeded the threshold; databases grew by 0.0 GB in the selected window.

What is happening

Right now, the error/log stream is active; sessions are waiting on blockers or deadlock-prone paths; long requests are still consuming time and may hold locks.

What happens next

Blocking and deadlock pressure is likely to repeat under the same workload until the blocking pattern is removed. Pressure indicators: 3,181 projected runtime events in 24 hours, 12 action signals, 2 watch signals. The likely outcome is operational impact or missed recovery objectives unless the first action is handled immediately.

Actions to break the trend 3
P1
Workload

Trace blockers/deadlocks to statement, index, and transaction order.

Concurrency incidents usually repeat under the same application path until the blocking pattern is removed.
P1
Logs

Group latest log errors by message and correlate with jobs, releases, and login sources.

The page sees a repeated symptom; grouping tells whether this is one noisy source or a wider server problem.
P2
Queries

Review SPID 0, waits, plan, and blockers before killing or tuning.

Long requests can be the cause of blocking, job delays, TempDB growth, or log pressure.
Trend and signal mix Rising risk
0 Backups
0 Disk
0 Jobs
3181 Logs
12 Locks
1 Queries
0 Gaps
3181 log/runtime 12 blocking 1 long query
Concrete findings 12
Logs 2,779 Errors

2026-09-02 10:14 - (@MinEvidenceTime datetime) CREATE TABLE #SqlBackupLog ( LogDate datetime NULL, ProcessInfo nvarchar(64) NULL, [Text] nvarchar(max) NULL ); DECLAR...

Logs 206 Timeouts

2026-09-02 10:14 - (@MinEvidenceTime datetime) CREATE TABLE #SqlBackupLog ( LogDate datetime NULL, ProcessInfo nvarchar(64) NULL, [Text] nvarchar(max) NULL ); DECLAR...

Logs 98 Login failures

2026-09-02 10:14 - (@MinEvidenceTime datetime) CREATE TABLE #SqlBackupLog ( LogDate datetime NULL, ProcessInfo nvarchar(64) NULL, [Text] nvarchar(max) NULL ); DECLAR...

Logs 98 Memory grants

2026-09-02 10:14 - (@MinEvidenceTime datetime) CREATE TABLE #SqlBackupLog ( LogDate datetime NULL, ProcessInfo nvarchar(64) NULL, [Text] nvarchar(max) NULL ); DECLAR...

Deadlocks master

2026-09-02 10:00 - <event name="xml_deadlock_report" package="sqlserver" timestamp="2026-09-02T10:00:11.446Z"><data name="xml_report"><value><deadlock><victim-list><vict...

Deadlocks database unknown

2026-09-02 10:00 - <event name="xml_deadlock_report" package="sqlserver" timestamp="2026-09-02T10:00:11.446Z"><data name="xml_report"><type name="xml" package="package0"...

Blocking DBAChaos

2026-09-01 23:01 - EXEC dbo.usp_Chaos_BlockedSession;

Blocking DBAChaos

2026-09-01 11:01 - EXEC dbo.usp_Chaos_BlockedSession;

Long running DBAChaos

SPID 0, 71s, wait completed cached query. UPDATE dbo.ChaosLock SET Payload = Payload + 1, ModifiedUtc = SYSUTCDATETIME() WHERE LockId = 3

Growth dbNexia_db

0.0 GB growth (Log ).

Largest DB dbNexia_db

0.9 GB current size.

Largest DB DOM_ShadowRiver_9AF6

0.1 GB current size.

Metrics and evidence Signals

Last OK 2026-09-02 10:15, last failed -. 3181 runtime events. 10 deadlocks / 2 blocking. 1 long running. 0.0 GB growth.

Recommended action Identify blockers, statements, and transaction order; prioritize indexing or code changes.
Pattern Repeated blocking or deadlocks indicate a transaction, query, or indexing pattern.
Forecast Blocking and deadlock pressure is likely to repeat under the same workload until the blocking pattern is removed.
Break the trend remove blocker/deadlock source; triage latest log errors; tune or reschedule long running requests.
CPU / memory free 1.0% / 55.4%
TempDB data / log 11.8% / 30.9%
Growth now / 7d forecast 0.0 GB / 0.0 GB
Runtime / 24h forecast 3181 / 3181
Backups / disks / jobs 0 / 0 / 0
Blocking / long queries 12 / 1
Telemetry gaps 0
Largest database 0.9 GB
Operating profile Test
Type SQL Server
Environment Test
Repository size 1.39 GB
Last OK 2026-09-02 10:15
Last failed -
Data quality 100%
Source confidence 0 gaps
AuditLog Available

dbNexia_db.dbo.AuditLog

DbSizes Available

dbNexia_db.dbo.dbsizes

EventLog Available

dbNexia_db.dbo.EventLog

LiveRequests Available

VIEW SERVER STATE permission

MsdbAgent Available

msdb SQL Agent history

MsdbBackup Available

msdb.dbo.backupset

ServerMetrics Available

dbNexia_db.dbo.ServerMetrics

TempDb Available

VIEW SERVER STATE permission

VolumeStats Available

VIEW SERVER STATE permission

Runtime 3181 events

Errors 2,779, timeouts 206, login failures 98, CPU warnings 0, memory grants 98.

(@MinEvidenceTime datetime) CREATE TABLE #SqlBackupLog ( LogDate datetime NULL, ProcessInfo nvarchar(64) NULL, [Text] nvarchar(max) NULL ); DECLAR...

Meaning

database 'Errors 2,779, timeouts 206, login failures 98, CPU warnings 0, memory grants 98.' needs a newer log backup in the SQL backup chain.

Recommended fix

Run or repair the log-backup job for database 'Errors 2,779, timeouts 206, login failures 98, CPU warnings 0, memory grants 98.'. If the log still cannot truncate, fix the specific blocker: open transaction, replication/AG send queue, backup target failure, or full-backup chain reset.

Verify

Open Backup History for the database and confirm a newer successful backup row of the missing type appears after the fix.

Backup risks0
BackupsNo risks

No backup risks detected for this server.

Storage0 low volumes
StorageNo low volumes

No low free-space volumes detected for this server.

Growth0.0 GB
dbNexia_db6.0 MB

Log growth inside the selected 24h window.

Meaning and fix

Meaning: This signal is abnormal, but the row text is not specific enough to name a single root cause with confidence.

Fix: Use the row values already shown here to filter the related report by the same server, database/job/login and the same time window.

Verify: The signal should stop repeating in the next collection window after the underlying job, permission, backup, or workload issue is fixed.

Queries and concurrency13 signals
Long running SPID 071s

DBAChaos; wait completed cached query; blocked by -; UPDATE dbo.ChaosLock SET Payload = Payload + 1, ModifiedUtc = SYSUTCDATETIME() WHERE LockId = 3

Meaning and fix

Meaning: A session is waiting because another transaction is holding a lock it needs.

Fix: Open the blocking or long-running detail row, use the shown blocking session and database, then stop the blocking transaction or fix the statement/index that makes it hold locks too long.

Verify: The blocking report should no longer show the same blocking session/database combination, and waiting requests should complete.

Deadlock2026-09-02 10:00

master; <event name="xml_deadlock_report" package="sqlserver" timestamp="2026-09-02T10:00:11.446Z"><data name="xml_report"><value><deadlock><victim-list><vict...

Meaning and fix

Meaning: SQL Server detected two sessions holding resources in conflicting order and chose one session as the deadlock victim.

Fix: Use the deadlock event details to identify the two statements and objects. Add the missing supporting index or change the transaction order so both code paths touch objects in the same order.

Verify: After the change, the same database/object pair should stop producing deadlock events in the selected lookback window.

Deadlock2026-09-02 10:00

database unknown; <event name="xml_deadlock_report" package="sqlserver" timestamp="2026-09-02T10:00:11.446Z"><data name="xml_report"><type name="xml" package="package0"...

Meaning and fix

Meaning: SQL Server detected two sessions holding resources in conflicting order and chose one session as the deadlock victim.

Fix: Use the deadlock event details to identify the two statements and objects. Add the missing supporting index or change the transaction order so both code paths touch objects in the same order.

Verify: After the change, the same database/object pair should stop producing deadlock events in the selected lookback window.

Deadlock2026-09-02 10:00

database unknown; <event name="xml_deadlock_report" package="sqlserver" timestamp="2026-09-02T10:00:11.446Z"><data name="xml_report"><value><deadlock><victim-list><vict...

Meaning and fix

Meaning: SQL Server detected two sessions holding resources in conflicting order and chose one session as the deadlock victim.

Fix: Use the deadlock event details to identify the two statements and objects. Add the missing supporting index or change the transaction order so both code paths touch objects in the same order.

Verify: After the change, the same database/object pair should stop producing deadlock events in the selected lookback window.

Deadlock2026-09-02 07:00

database unknown; <event name="xml_deadlock_report" package="sqlserver" timestamp="2026-09-02T07:00:09.850Z"><data name="xml_report"><type name="xml" package="package0"...

Meaning and fix

Meaning: SQL Server detected two sessions holding resources in conflicting order and chose one session as the deadlock victim.

Fix: Use the deadlock event details to identify the two statements and objects. Add the missing supporting index or change the transaction order so both code paths touch objects in the same order.

Verify: After the change, the same database/object pair should stop producing deadlock events in the selected lookback window.

Deadlock2026-09-02 07:00

database unknown; <event name="xml_deadlock_report" package="sqlserver" timestamp="2026-09-02T07:00:09.850Z"><data name="xml_report"><value><deadlock><victim-list><vict...

Meaning and fix

Meaning: SQL Server detected two sessions holding resources in conflicting order and chose one session as the deadlock victim.

Fix: Use the deadlock event details to identify the two statements and objects. Add the missing supporting index or change the transaction order so both code paths touch objects in the same order.

Verify: After the change, the same database/object pair should stop producing deadlock events in the selected lookback window.

Blocking2026-09-01 23:01

DBAChaos; SPID 19; EXEC dbo.usp_Chaos_BlockedSession;

Meaning and fix

Meaning: A session is waiting because another transaction is holding a lock it needs.

Fix: Open the blocking or long-running detail row, use the shown blocking session and database, then stop the blocking transaction or fix the statement/index that makes it hold locks too long.

Verify: The blocking report should no longer show the same blocking session/database combination, and waiting requests should complete.

Blocking2026-09-01 11:01

DBAChaos; SPID 19; EXEC dbo.usp_Chaos_BlockedSession;

Meaning and fix

Meaning: A session is waiting because another transaction is holding a lock it needs.

Fix: Open the blocking or long-running detail row, use the shown blocking session and database, then stop the blocking transaction or fix the statement/index that makes it hold locks too long.

Verify: The blocking report should no longer show the same blocking session/database combination, and waiting requests should complete.

Largest databases and job failures0 job failures
dbNexia_db0.9 GB

Current largest database inventory sample.

DOM_ShadowRiver_9AF60.1 GB

Current largest database inventory sample.

DOM_WhisperEcho_929E0.1 GB

Current largest database inventory sample.

MAL_MAINT_DB_old0.1 GB

Current largest database inventory sample.

DOM_ForestEcho_B4A40.1 GB

Current largest database inventory sample.

DOM_ForestSky_5A7D0.0 GB

Current largest database inventory sample.

DOM_DreamStone_57220.0 GB

Current largest database inventory sample.

DBAChaos0.0 GB

Current largest database inventory sample.

tempdb0.0 GB

Current largest database inventory sample.

JobsNo failures

No SQL Agent job failures detected in this window.

Critical

SERVER 4

TESTSRV_4.DBNEXIA.COM / Test / SQL Server / Last seen 2026-09-02 10:15
Health0
Pressure100
TrendDeteriorating
DirectionRising risk
Best advice

P1 Workload: Trace blockers/deadlocks to statement, index, and transaction order. This is first because concurrency incidents usually repeat under the same application path until the blocking pattern is removed. Pattern: Repeated blocking or deadlocks indicate a transaction, query, or indexing pattern.

Dashboard Report
What happened

In the selected window, 219 log/runtime events were recorded, latest at 2026-09-02 10:14; 10 deadlocks and 2 blocking events appeared; 1 long running requests exceeded the threshold; databases grew by 0.0 GB in the selected window.

What is happening

Right now, the error/log stream is active; sessions are waiting on blockers or deadlock-prone paths; long requests are still consuming time and may hold locks.

What happens next

Blocking and deadlock pressure is likely to repeat under the same workload until the blocking pattern is removed. Pressure indicators: 219 projected runtime events in 24 hours, 12 action signals, 2 watch signals. The likely outcome is operational impact or missed recovery objectives unless the first action is handled immediately.

Actions to break the trend 3
P1
Workload

Trace blockers/deadlocks to statement, index, and transaction order.

Concurrency incidents usually repeat under the same application path until the blocking pattern is removed.
P1
Logs

Group latest log errors by message and correlate with jobs, releases, and login sources.

The page sees a repeated symptom; grouping tells whether this is one noisy source or a wider server problem.
P2
Queries

Review SPID 0, waits, plan, and blockers before killing or tuning.

Long requests can be the cause of blocking, job delays, TempDB growth, or log pressure.
Trend and signal mix Rising risk
0 Backups
0 Disk
0 Jobs
219 Logs
12 Locks
1 Queries
0 Gaps
219 log/runtime 12 blocking 1 long query
Concrete findings 12
Logs 104 Errors

2026-09-02 10:14 - (@MinEvidenceTime datetime) CREATE TABLE #SqlBackupLog ( LogDate datetime NULL, ProcessInfo nvarchar(64) NULL, [Text] nvarchar(max) NULL ); DECLAR...

Logs 113 Timeouts

2026-09-02 10:14 - (@MinEvidenceTime datetime) CREATE TABLE #SqlBackupLog ( LogDate datetime NULL, ProcessInfo nvarchar(64) NULL, [Text] nvarchar(max) NULL ); DECLAR...

Logs 1 Login failures

2026-09-02 10:14 - (@MinEvidenceTime datetime) CREATE TABLE #SqlBackupLog ( LogDate datetime NULL, ProcessInfo nvarchar(64) NULL, [Text] nvarchar(max) NULL ); DECLAR...

Logs 1 Memory grants

2026-09-02 10:14 - (@MinEvidenceTime datetime) CREATE TABLE #SqlBackupLog ( LogDate datetime NULL, ProcessInfo nvarchar(64) NULL, [Text] nvarchar(max) NULL ); DECLAR...

Deadlocks master

2026-09-02 10:00 - <event name="xml_deadlock_report" package="sqlserver" timestamp="2026-09-02T10:00:11.319Z"><data name="xml_report"><value><deadlock><victim-list><vict...

Deadlocks database unknown

2026-09-02 10:00 - <event name="xml_deadlock_report" package="sqlserver" timestamp="2026-09-02T10:00:11.319Z"><data name="xml_report"><type name="xml" package="package0"...

Blocking DBAChaos

2026-09-02 09:01 - EXEC dbo.usp_Chaos_BlockedSession;

Blocking DBAChaos

2026-09-02 08:01 - EXEC dbo.usp_Chaos_BlockedSession;

Long running DBAChaos

SPID 0, 71s, wait completed cached query. UPDATE dbo.ChaosLock SET Payload = Payload + 1, ModifiedUtc = SYSUTCDATETIME() WHERE LockId = 3

Growth dbNexia_db

0.0 GB growth (Log ).

Largest DB dbNexia_db

0.4 GB current size.

Largest DB DBAChaos

0.0 GB current size.

Metrics and evidence Signals

Last OK 2026-09-02 10:15, last failed -. 219 runtime events. 10 deadlocks / 2 blocking. 1 long running. 0.0 GB growth.

Recommended action Identify blockers, statements, and transaction order; prioritize indexing or code changes.
Pattern Repeated blocking or deadlocks indicate a transaction, query, or indexing pattern.
Forecast Blocking and deadlock pressure is likely to repeat under the same workload until the blocking pattern is removed.
Break the trend remove blocker/deadlock source; triage latest log errors; tune or reschedule long running requests.
CPU / memory free 1.0% / 55.4%
TempDB data / log 13.6% / 12.3%
Growth now / 7d forecast 0.0 GB / 0.0 GB
Runtime / 24h forecast 219 / 219
Backups / disks / jobs 0 / 0 / 0
Blocking / long queries 12 / 1
Telemetry gaps 0
Largest database 0.4 GB
Operating profile Test
Type SQL Server
Environment Test
Repository size 1.33 GB
Last OK 2026-09-02 10:15
Last failed -
Data quality 100%
Source confidence 0 gaps
AuditLog Available

dbNexia_db.dbo.AuditLog

DbSizes Available

dbNexia_db.dbo.dbsizes

EventLog Available

dbNexia_db.dbo.EventLog

LiveRequests Available

VIEW SERVER STATE permission

MsdbAgent Available

msdb SQL Agent history

MsdbBackup Available

msdb.dbo.backupset

ServerMetrics Available

dbNexia_db.dbo.ServerMetrics

TempDb Available

VIEW SERVER STATE permission

VolumeStats Available

VIEW SERVER STATE permission

Runtime 219 events

Errors 104, timeouts 113, login failures 1, CPU warnings 0, memory grants 1.

(@MinEvidenceTime datetime) CREATE TABLE #SqlBackupLog ( LogDate datetime NULL, ProcessInfo nvarchar(64) NULL, [Text] nvarchar(max) NULL ); DECLAR...

Meaning

database 'Errors 104, timeouts 113, login failures 1, CPU warnings 0, memory grants 1.' needs a newer log backup in the SQL backup chain.

Recommended fix

Run or repair the log-backup job for database 'Errors 104, timeouts 113, login failures 1, CPU warnings 0, memory grants 1.'. If the log still cannot truncate, fix the specific blocker: open transaction, replication/AG send queue, backup target failure, or full-backup chain reset.

Verify

Open Backup History for the database and confirm a newer successful backup row of the missing type appears after the fix.

Backup risks0
BackupsNo risks

No backup risks detected for this server.

Storage0 low volumes
StorageNo low volumes

No low free-space volumes detected for this server.

Growth0.0 GB
dbNexia_db5.0 MB

Log growth inside the selected 24h window.

Meaning and fix

Meaning: This signal is abnormal, but the row text is not specific enough to name a single root cause with confidence.

Fix: Use the row values already shown here to filter the related report by the same server, database/job/login and the same time window.

Verify: The signal should stop repeating in the next collection window after the underlying job, permission, backup, or workload issue is fixed.

Queries and concurrency13 signals
Long running SPID 071s

DBAChaos; wait completed cached query; blocked by -; UPDATE dbo.ChaosLock SET Payload = Payload + 1, ModifiedUtc = SYSUTCDATETIME() WHERE LockId = 3

Meaning and fix

Meaning: A session is waiting because another transaction is holding a lock it needs.

Fix: Open the blocking or long-running detail row, use the shown blocking session and database, then stop the blocking transaction or fix the statement/index that makes it hold locks too long.

Verify: The blocking report should no longer show the same blocking session/database combination, and waiting requests should complete.

Deadlock2026-09-02 10:00

master; <event name="xml_deadlock_report" package="sqlserver" timestamp="2026-09-02T10:00:11.319Z"><data name="xml_report"><value><deadlock><victim-list><vict...

Meaning and fix

Meaning: SQL Server detected two sessions holding resources in conflicting order and chose one session as the deadlock victim.

Fix: Use the deadlock event details to identify the two statements and objects. Add the missing supporting index or change the transaction order so both code paths touch objects in the same order.

Verify: After the change, the same database/object pair should stop producing deadlock events in the selected lookback window.

Deadlock2026-09-02 10:00

database unknown; <event name="xml_deadlock_report" package="sqlserver" timestamp="2026-09-02T10:00:11.319Z"><data name="xml_report"><type name="xml" package="package0"...

Meaning and fix

Meaning: SQL Server detected two sessions holding resources in conflicting order and chose one session as the deadlock victim.

Fix: Use the deadlock event details to identify the two statements and objects. Add the missing supporting index or change the transaction order so both code paths touch objects in the same order.

Verify: After the change, the same database/object pair should stop producing deadlock events in the selected lookback window.

Deadlock2026-09-02 10:00

database unknown; <event name="xml_deadlock_report" package="sqlserver" timestamp="2026-09-02T10:00:11.319Z"><data name="xml_report"><value><deadlock><victim-list><vict...

Meaning and fix

Meaning: SQL Server detected two sessions holding resources in conflicting order and chose one session as the deadlock victim.

Fix: Use the deadlock event details to identify the two statements and objects. Add the missing supporting index or change the transaction order so both code paths touch objects in the same order.

Verify: After the change, the same database/object pair should stop producing deadlock events in the selected lookback window.

Deadlock2026-09-02 06:00

master; <event name="xml_deadlock_report" package="sqlserver" timestamp="2026-09-02T06:00:11.725Z"><data name="xml_report"><value><deadlock><victim-list><vict...

Meaning and fix

Meaning: SQL Server detected two sessions holding resources in conflicting order and chose one session as the deadlock victim.

Fix: Use the deadlock event details to identify the two statements and objects. Add the missing supporting index or change the transaction order so both code paths touch objects in the same order.

Verify: After the change, the same database/object pair should stop producing deadlock events in the selected lookback window.

Deadlock2026-09-02 06:00

database unknown; <event name="xml_deadlock_report" package="sqlserver" timestamp="2026-09-02T06:00:11.725Z"><data name="xml_report"><type name="xml" package="package0"...

Meaning and fix

Meaning: SQL Server detected two sessions holding resources in conflicting order and chose one session as the deadlock victim.

Fix: Use the deadlock event details to identify the two statements and objects. Add the missing supporting index or change the transaction order so both code paths touch objects in the same order.

Verify: After the change, the same database/object pair should stop producing deadlock events in the selected lookback window.

Blocking2026-09-02 09:01

DBAChaos; SPID 19; EXEC dbo.usp_Chaos_BlockedSession;

Meaning and fix

Meaning: A session is waiting because another transaction is holding a lock it needs.

Fix: Open the blocking or long-running detail row, use the shown blocking session and database, then stop the blocking transaction or fix the statement/index that makes it hold locks too long.

Verify: The blocking report should no longer show the same blocking session/database combination, and waiting requests should complete.

Blocking2026-09-02 08:01

DBAChaos; SPID 19; EXEC dbo.usp_Chaos_BlockedSession;

Meaning and fix

Meaning: A session is waiting because another transaction is holding a lock it needs.

Fix: Open the blocking or long-running detail row, use the shown blocking session and database, then stop the blocking transaction or fix the statement/index that makes it hold locks too long.

Verify: The blocking report should no longer show the same blocking session/database combination, and waiting requests should complete.

Largest databases and job failures0 job failures
dbNexia_db0.4 GB

Current largest database inventory sample.

DBAChaos0.0 GB

Current largest database inventory sample.

tempdb0.0 GB

Current largest database inventory sample.

JobsNo failures

No SQL Agent job failures detected in this window.

Critical

SERVER 1

TESTSRV_1.DBNEXIA.COM / Test / SQL Server / Last seen 2026-09-02 10:15
Health0
Pressure100
TrendDeteriorating
DirectionRising risk
Best advice

P1 Workload: Trace blockers/deadlocks to statement, index, and transaction order. This is first because concurrency incidents usually repeat under the same application path until the blocking pattern is removed. Pattern: Repeated blocking or deadlocks indicate a transaction, query, or indexing pattern.

Dashboard Report
What happened

In the selected window, 3271 log/runtime events were recorded, latest at 2026-09-02 10:14; 10 deadlocks and 0 blocking events appeared; 1 long running requests exceeded the threshold; databases grew by 0.0 GB in the selected window.

What is happening

Right now, the error/log stream is active; sessions are waiting on blockers or deadlock-prone paths; long requests are still consuming time and may hold locks.

What happens next

Blocking and deadlock pressure is likely to repeat under the same workload until the blocking pattern is removed. Pressure indicators: 3,271 projected runtime events in 24 hours, 10 action signals, 2 watch signals. The likely outcome is operational impact or missed recovery objectives unless the first action is handled immediately.

Actions to break the trend 3
P1
Workload

Trace blockers/deadlocks to statement, index, and transaction order.

Concurrency incidents usually repeat under the same application path until the blocking pattern is removed.
P1
Logs

Group latest log errors by message and correlate with jobs, releases, and login sources.

The page sees a repeated symptom; grouping tells whether this is one noisy source or a wider server problem.
P2
Queries

Review SPID 0, waits, plan, and blockers before killing or tuning.

Long requests can be the cause of blocking, job delays, TempDB growth, or log pressure.
Trend and signal mix Rising risk
0 Backups
0 Disk
0 Jobs
3271 Logs
10 Locks
1 Queries
0 Gaps
3271 log/runtime 10 blocking 1 long query
Concrete findings 12
Logs 2,865 Errors

2026-09-02 10:14 - (@MinEvidenceTime datetime) CREATE TABLE #SqlBackupLog ( LogDate datetime NULL, ProcessInfo nvarchar(64) NULL, [Text] nvarchar(max) NULL ); DECLAR...

Logs 208 Timeouts

2026-09-02 10:14 - (@MinEvidenceTime datetime) CREATE TABLE #SqlBackupLog ( LogDate datetime NULL, ProcessInfo nvarchar(64) NULL, [Text] nvarchar(max) NULL ); DECLAR...

Logs 99 Login failures

2026-09-02 10:14 - (@MinEvidenceTime datetime) CREATE TABLE #SqlBackupLog ( LogDate datetime NULL, ProcessInfo nvarchar(64) NULL, [Text] nvarchar(max) NULL ); DECLAR...

Logs 99 Memory grants

2026-09-02 10:14 - (@MinEvidenceTime datetime) CREATE TABLE #SqlBackupLog ( LogDate datetime NULL, ProcessInfo nvarchar(64) NULL, [Text] nvarchar(max) NULL ); DECLAR...

Deadlocks database unknown

2026-09-02 10:00 - <event name="xml_deadlock_report" package="sqlserver" timestamp="2026-09-02T10:00:08.877Z"><data name="xml_report"><type name="xml" package="package0"...

Deadlocks database unknown

2026-09-02 10:00 - <event name="xml_deadlock_report" package="sqlserver" timestamp="2026-09-02T10:00:08.877Z"><data name="xml_report"><value><deadlock><victim-list><vict...

Long running DBAChaos

SPID 0, 71s, wait completed cached query. UPDATE dbo.ChaosLock SET Payload = Payload + 1, ModifiedUtc = SYSUTCDATETIME() WHERE LockId = 3

Growth tempdb

0.0 GB growth (Data ).

Largest DB dbNexia_db

0.9 GB current size.

Largest DB MAL_MAINT_DB_old

0.1 GB current size.

Resources CPU and memory

CPU 1.0%, memory free 55.4%, users 1, transactions 7.

TempDB Data and log

Data 10.5%, log 9.2%, version store 0 MB.

Metrics and evidence Signals

Last OK 2026-09-02 10:15, last failed -. 3271 runtime events. 10 deadlocks / 0 blocking. 1 long running. 0.0 GB growth.

Recommended action Identify blockers, statements, and transaction order; prioritize indexing or code changes.
Pattern Repeated blocking or deadlocks indicate a transaction, query, or indexing pattern.
Forecast Blocking and deadlock pressure is likely to repeat under the same workload until the blocking pattern is removed.
Break the trend remove blocker/deadlock source; triage latest log errors; tune or reschedule long running requests.
CPU / memory free 1.0% / 55.4%
TempDB data / log 10.5% / 9.2%
Growth now / 7d forecast 0.0 GB / 0.0 GB
Runtime / 24h forecast 3271 / 3271
Backups / disks / jobs 0 / 0 / 0
Blocking / long queries 10 / 1
Telemetry gaps 0
Largest database 0.9 GB
Operating profile Test
Type SQL Server
Environment Test
Repository size 1.39 GB
Last OK 2026-09-02 10:15
Last failed -
Data quality 100%
Source confidence 0 gaps
AuditLog Available

dbNexia_db.dbo.AuditLog

DbSizes Available

dbNexia_db.dbo.dbsizes

EventLog Available

dbNexia_db.dbo.EventLog

LiveRequests Available

VIEW SERVER STATE permission

MsdbAgent Available

msdb SQL Agent history

MsdbBackup Available

msdb.dbo.backupset

ServerMetrics Available

dbNexia_db.dbo.ServerMetrics

TempDb Available

VIEW SERVER STATE permission

VolumeStats Available

VIEW SERVER STATE permission

Runtime 3271 events

Errors 2,865, timeouts 208, login failures 99, CPU warnings 0, memory grants 99.

(@MinEvidenceTime datetime) CREATE TABLE #SqlBackupLog ( LogDate datetime NULL, ProcessInfo nvarchar(64) NULL, [Text] nvarchar(max) NULL ); DECLAR...

Meaning

database 'Errors 2,865, timeouts 208, login failures 99, CPU warnings 0, memory grants 99.' needs a newer log backup in the SQL backup chain.

Recommended fix

Run or repair the log-backup job for database 'Errors 2,865, timeouts 208, login failures 99, CPU warnings 0, memory grants 99.'. If the log still cannot truncate, fix the specific blocker: open transaction, replication/AG send queue, backup target failure, or full-backup chain reset.

Verify

Open Backup History for the database and confirm a newer successful backup row of the missing type appears after the fix.

Backup risks0
BackupsNo risks

No backup risks detected for this server.

Storage0 low volumes
StorageNo low volumes

No low free-space volumes detected for this server.

Growth0.0 GB
tempdb4.0 MB

Data growth inside the selected 24h window.

Meaning and fix

Meaning: This signal is abnormal, but the row text is not specific enough to name a single root cause with confidence.

Fix: Use the row values already shown here to filter the related report by the same server, database/job/login and the same time window.

Verify: The signal should stop repeating in the next collection window after the underlying job, permission, backup, or workload issue is fixed.

Queries and concurrency11 signals
Long running SPID 071s

DBAChaos; wait completed cached query; blocked by -; UPDATE dbo.ChaosLock SET Payload = Payload + 1, ModifiedUtc = SYSUTCDATETIME() WHERE LockId = 3

Meaning and fix

Meaning: A session is waiting because another transaction is holding a lock it needs.

Fix: Open the blocking or long-running detail row, use the shown blocking session and database, then stop the blocking transaction or fix the statement/index that makes it hold locks too long.

Verify: The blocking report should no longer show the same blocking session/database combination, and waiting requests should complete.

Deadlock2026-09-02 10:00

database unknown; <event name="xml_deadlock_report" package="sqlserver" timestamp="2026-09-02T10:00:08.877Z"><data name="xml_report"><type name="xml" package="package0"...

Meaning and fix

Meaning: SQL Server detected two sessions holding resources in conflicting order and chose one session as the deadlock victim.

Fix: Use the deadlock event details to identify the two statements and objects. Add the missing supporting index or change the transaction order so both code paths touch objects in the same order.

Verify: After the change, the same database/object pair should stop producing deadlock events in the selected lookback window.

Deadlock2026-09-02 10:00

database unknown; <event name="xml_deadlock_report" package="sqlserver" timestamp="2026-09-02T10:00:08.877Z"><data name="xml_report"><value><deadlock><victim-list><vict...

Meaning and fix

Meaning: SQL Server detected two sessions holding resources in conflicting order and chose one session as the deadlock victim.

Fix: Use the deadlock event details to identify the two statements and objects. Add the missing supporting index or change the transaction order so both code paths touch objects in the same order.

Verify: After the change, the same database/object pair should stop producing deadlock events in the selected lookback window.

Deadlock2026-09-02 10:00

master; <event name="xml_deadlock_report" package="sqlserver" timestamp="2026-09-02T10:00:08.877Z"><data name="xml_report"><value><deadlock><victim-list><vict...

Meaning and fix

Meaning: SQL Server detected two sessions holding resources in conflicting order and chose one session as the deadlock victim.

Fix: Use the deadlock event details to identify the two statements and objects. Add the missing supporting index or change the transaction order so both code paths touch objects in the same order.

Verify: After the change, the same database/object pair should stop producing deadlock events in the selected lookback window.

Deadlock2026-09-02 03:00

master; <event name="xml_deadlock_report" package="sqlserver" timestamp="2026-09-02T03:00:09.449Z"><data name="xml_report"><value><deadlock><victim-list><vict...

Meaning and fix

Meaning: SQL Server detected two sessions holding resources in conflicting order and chose one session as the deadlock victim.

Fix: Use the deadlock event details to identify the two statements and objects. Add the missing supporting index or change the transaction order so both code paths touch objects in the same order.

Verify: After the change, the same database/object pair should stop producing deadlock events in the selected lookback window.

Deadlock2026-09-02 03:00

database unknown; <event name="xml_deadlock_report" package="sqlserver" timestamp="2026-09-02T03:00:09.449Z"><data name="xml_report"><value><deadlock><victim-list><vict...

Meaning and fix

Meaning: SQL Server detected two sessions holding resources in conflicting order and chose one session as the deadlock victim.

Fix: Use the deadlock event details to identify the two statements and objects. Add the missing supporting index or change the transaction order so both code paths touch objects in the same order.

Verify: After the change, the same database/object pair should stop producing deadlock events in the selected lookback window.

Largest databases and job failures0 job failures
dbNexia_db0.9 GB

Current largest database inventory sample.

MAL_MAINT_DB_old0.1 GB

Current largest database inventory sample.

DOM_DreamBlossom_D66E0.1 GB

Current largest database inventory sample.

DOM_ThunderMoon_622B0.1 GB

Current largest database inventory sample.

DOM_ShadowWhisper_67B10.1 GB

Current largest database inventory sample.

DOM_ForestDream_BD6D0.1 GB

Current largest database inventory sample.

DOM_BlossomWhisper_FDD30.0 GB

Current largest database inventory sample.

DBAChaos0.0 GB

Current largest database inventory sample.

tempdb0.0 GB

Current largest database inventory sample.

JobsNo failures

No SQL Agent job failures detected in this window.

Critical

SERVER 3

TESTSRV_3.DBNEXIA.COM / Test / SQL Server / Last seen 2026-09-02 10:15
Health0
Pressure100
TrendDeteriorating
DirectionRising risk
Best advice

P1 Workload: Trace blockers/deadlocks to statement, index, and transaction order. This is first because concurrency incidents usually repeat under the same application path until the blocking pattern is removed. Pattern: Repeated blocking or deadlocks indicate a transaction, query, or indexing pattern.

Dashboard Report
What happened

In the selected window, 3186 log/runtime events were recorded, latest at 2026-09-02 10:14; 10 deadlocks and 0 blocking events appeared; databases grew by 0.0 GB in the selected window.

What is happening

Right now, the error/log stream is active; sessions are waiting on blockers or deadlock-prone paths.

What happens next

Blocking and deadlock pressure is likely to repeat under the same workload until the blocking pattern is removed. Pressure indicators: 3,186 projected runtime events in 24 hours, 10 action signals, 1 watch signals. The likely outcome is operational impact or missed recovery objectives unless the first action is handled immediately.

Actions to break the trend 2
P1
Workload

Trace blockers/deadlocks to statement, index, and transaction order.

Concurrency incidents usually repeat under the same application path until the blocking pattern is removed.
P1
Logs

Group latest log errors by message and correlate with jobs, releases, and login sources.

The page sees a repeated symptom; grouping tells whether this is one noisy source or a wider server problem.
Trend and signal mix Rising risk
0 Backups
0 Disk
0 Jobs
3186 Logs
10 Locks
0 Queries
0 Gaps
3186 log/runtime 10 blocking
Concrete findings 11
Logs 2,779 Errors

2026-09-02 10:14 - (@MinEvidenceTime datetime) CREATE TABLE #SqlBackupLog ( LogDate datetime NULL, ProcessInfo nvarchar(64) NULL, [Text] nvarchar(max) NULL ); DECLAR...

Logs 207 Timeouts

2026-09-02 10:14 - (@MinEvidenceTime datetime) CREATE TABLE #SqlBackupLog ( LogDate datetime NULL, ProcessInfo nvarchar(64) NULL, [Text] nvarchar(max) NULL ); DECLAR...

Logs 100 Login failures

2026-09-02 10:14 - (@MinEvidenceTime datetime) CREATE TABLE #SqlBackupLog ( LogDate datetime NULL, ProcessInfo nvarchar(64) NULL, [Text] nvarchar(max) NULL ); DECLAR...

Logs 100 Memory grants

2026-09-02 10:14 - (@MinEvidenceTime datetime) CREATE TABLE #SqlBackupLog ( LogDate datetime NULL, ProcessInfo nvarchar(64) NULL, [Text] nvarchar(max) NULL ); DECLAR...

Deadlocks database unknown

2026-09-02 08:00 - <event name="xml_deadlock_report" package="sqlserver" timestamp="2026-09-02T08:00:10.207Z"><data name="xml_report"><type name="xml" package="package0"...

Deadlocks database unknown

2026-09-02 08:00 - <event name="xml_deadlock_report" package="sqlserver" timestamp="2026-09-02T08:00:10.207Z"><data name="xml_report"><value><deadlock><victim-list><vict...

Growth dbNexia_db

0.0 GB growth (Log ).

Largest DB dbNexia_db

1.0 GB current size.

Largest DB DOM_CrystalStone_911A

0.1 GB current size.

Resources CPU and memory

CPU 1.0%, memory free 55.4%, users 1, transactions 7.

TempDB Data and log

Data 15.6%, log 24.1%, version store 0 MB.

Metrics and evidence Signals

Last OK 2026-09-02 10:15, last failed -. 3186 runtime events. 10 deadlocks / 0 blocking. 0.0 GB growth. CPU 1.0%, memory free 55.4%.

Recommended action Identify blockers, statements, and transaction order; prioritize indexing or code changes.
Pattern Repeated blocking or deadlocks indicate a transaction, query, or indexing pattern.
Forecast Blocking and deadlock pressure is likely to repeat under the same workload until the blocking pattern is removed.
Break the trend remove blocker/deadlock source; triage latest log errors.
CPU / memory free 1.0% / 55.4%
TempDB data / log 15.6% / 24.1%
Growth now / 7d forecast 0.0 GB / 0.0 GB
Runtime / 24h forecast 3186 / 3186
Backups / disks / jobs 0 / 0 / 0
Blocking / long queries 10 / 0
Telemetry gaps 0
Largest database 1.0 GB
Operating profile Test
Type SQL Server
Environment Test
Repository size 1.45 GB
Last OK 2026-09-02 10:15
Last failed -
Data quality 100%
Source confidence 0 gaps
AuditLog Available

dbNexia_db.dbo.AuditLog

DbSizes Available

dbNexia_db.dbo.dbsizes

EventLog Available

dbNexia_db.dbo.EventLog

LiveRequests Available

VIEW SERVER STATE permission

MsdbAgent Available

msdb SQL Agent history

MsdbBackup Available

msdb.dbo.backupset

ServerMetrics Available

dbNexia_db.dbo.ServerMetrics

TempDb Available

VIEW SERVER STATE permission

VolumeStats Available

VIEW SERVER STATE permission

Runtime 3186 events

Errors 2,779, timeouts 207, login failures 100, CPU warnings 0, memory grants 100.

(@MinEvidenceTime datetime) CREATE TABLE #SqlBackupLog ( LogDate datetime NULL, ProcessInfo nvarchar(64) NULL, [Text] nvarchar(max) NULL ); DECLAR...

Meaning

database 'Errors 2,779, timeouts 207, login failures 100, CPU warnings 0, memory grants 100.' needs a newer log backup in the SQL backup chain.

Recommended fix

Run or repair the log-backup job for database 'Errors 2,779, timeouts 207, login failures 100, CPU warnings 0, memory grants 100.'. If the log still cannot truncate, fix the specific blocker: open transaction, replication/AG send queue, backup target failure, or full-backup chain reset.

Verify

Open Backup History for the database and confirm a newer successful backup row of the missing type appears after the fix.

Backup risks0
BackupsNo risks

No backup risks detected for this server.

Storage0 low volumes
StorageNo low volumes

No low free-space volumes detected for this server.

Growth0.0 GB
dbNexia_db5.0 MB

Log growth inside the selected 24h window.

Meaning and fix

Meaning: This signal is abnormal, but the row text is not specific enough to name a single root cause with confidence.

Fix: Use the row values already shown here to filter the related report by the same server, database/job/login and the same time window.

Verify: The signal should stop repeating in the next collection window after the underlying job, permission, backup, or workload issue is fixed.

Queries and concurrency10 signals
Deadlock2026-09-02 08:00

database unknown; <event name="xml_deadlock_report" package="sqlserver" timestamp="2026-09-02T08:00:10.207Z"><data name="xml_report"><type name="xml" package="package0"...

Meaning and fix

Meaning: SQL Server detected two sessions holding resources in conflicting order and chose one session as the deadlock victim.

Fix: Use the deadlock event details to identify the two statements and objects. Add the missing supporting index or change the transaction order so both code paths touch objects in the same order.

Verify: After the change, the same database/object pair should stop producing deadlock events in the selected lookback window.

Deadlock2026-09-02 08:00

database unknown; <event name="xml_deadlock_report" package="sqlserver" timestamp="2026-09-02T08:00:10.207Z"><data name="xml_report"><value><deadlock><victim-list><vict...

Meaning and fix

Meaning: SQL Server detected two sessions holding resources in conflicting order and chose one session as the deadlock victim.

Fix: Use the deadlock event details to identify the two statements and objects. Add the missing supporting index or change the transaction order so both code paths touch objects in the same order.

Verify: After the change, the same database/object pair should stop producing deadlock events in the selected lookback window.

Deadlock2026-09-02 08:00

master; <event name="xml_deadlock_report" package="sqlserver" timestamp="2026-09-02T08:00:10.207Z"><data name="xml_report"><value><deadlock><victim-list><vict...

Meaning and fix

Meaning: SQL Server detected two sessions holding resources in conflicting order and chose one session as the deadlock victim.

Fix: Use the deadlock event details to identify the two statements and objects. Add the missing supporting index or change the transaction order so both code paths touch objects in the same order.

Verify: After the change, the same database/object pair should stop producing deadlock events in the selected lookback window.

Deadlock2026-09-02 07:00

master; <event name="xml_deadlock_report" package="sqlserver" timestamp="2026-09-02T07:00:09.656Z"><data name="xml_report"><value><deadlock><victim-list><vict...

Meaning and fix

Meaning: SQL Server detected two sessions holding resources in conflicting order and chose one session as the deadlock victim.

Fix: Use the deadlock event details to identify the two statements and objects. Add the missing supporting index or change the transaction order so both code paths touch objects in the same order.

Verify: After the change, the same database/object pair should stop producing deadlock events in the selected lookback window.

Deadlock2026-09-02 07:00

database unknown; <event name="xml_deadlock_report" package="sqlserver" timestamp="2026-09-02T07:00:09.656Z"><data name="xml_report"><type name="xml" package="package0"...

Meaning and fix

Meaning: SQL Server detected two sessions holding resources in conflicting order and chose one session as the deadlock victim.

Fix: Use the deadlock event details to identify the two statements and objects. Add the missing supporting index or change the transaction order so both code paths touch objects in the same order.

Verify: After the change, the same database/object pair should stop producing deadlock events in the selected lookback window.

Largest databases and job failures0 job failures
dbNexia_db1.0 GB

Current largest database inventory sample.

DOM_CrystalStone_911A0.1 GB

Current largest database inventory sample.

DOM_ShadowMoon_946A0.1 GB

Current largest database inventory sample.

MAL_MAINT_DB_old0.1 GB

Current largest database inventory sample.

DOM_ShadowOcean_44860.1 GB

Current largest database inventory sample.

DOM_FlameCrystal_07F40.0 GB

Current largest database inventory sample.

DOM_MoonCrystal_16FD0.0 GB

Current largest database inventory sample.

DBAChaos0.0 GB

Current largest database inventory sample.

tempdb0.0 GB

Current largest database inventory sample.

JobsNo failures

No SQL Agent job failures detected in this window.

Critical

SERVER 5

TESTSRV_5.DBNEXIA.COM / Test / SQL Server / Last seen 2026-09-02 10:15
Health0
Pressure100
TrendDeteriorating
DirectionRising risk
Best advice

P1 Workload: Trace blockers/deadlocks to statement, index, and transaction order. This is first because concurrency incidents usually repeat under the same application path until the blocking pattern is removed. Pattern: Repeated blocking or deadlocks indicate a transaction, query, or indexing pattern.

Dashboard Report
What happened

In the selected window, 206 log/runtime events were recorded, latest at 2026-09-02 10:14; 9 deadlocks and 0 blocking events appeared; 1 long running requests exceeded the threshold; databases grew by 0.0 GB in the selected window.

What is happening

Right now, the error/log stream is active; sessions are waiting on blockers or deadlock-prone paths; long requests are still consuming time and may hold locks.

What happens next

Blocking and deadlock pressure is likely to repeat under the same workload until the blocking pattern is removed. Pressure indicators: 206 projected runtime events in 24 hours, 9 action signals, 2 watch signals. The likely outcome is operational impact or missed recovery objectives unless the first action is handled immediately.

Actions to break the trend 3
P1
Workload

Trace blockers/deadlocks to statement, index, and transaction order.

Concurrency incidents usually repeat under the same application path until the blocking pattern is removed.
P1
Logs

Group latest log errors by message and correlate with jobs, releases, and login sources.

The page sees a repeated symptom; grouping tells whether this is one noisy source or a wider server problem.
P2
Queries

Review SPID 0, waits, plan, and blockers before killing or tuning.

Long requests can be the cause of blocking, job delays, TempDB growth, or log pressure.
Trend and signal mix Rising risk
0 Backups
0 Disk
0 Jobs
206 Logs
9 Locks
1 Queries
0 Gaps
206 log/runtime 9 blocking 1 long query
Concrete findings 10
Logs 102 Errors

2026-09-02 10:14 - (@MinEvidenceTime datetime) CREATE TABLE #SqlBackupLog ( LogDate datetime NULL, ProcessInfo nvarchar(64) NULL, [Text] nvarchar(max) NULL ); DECLAR...

Logs 104 Timeouts

2026-09-02 10:14 - (@MinEvidenceTime datetime) CREATE TABLE #SqlBackupLog ( LogDate datetime NULL, ProcessInfo nvarchar(64) NULL, [Text] nvarchar(max) NULL ); DECLAR...

Deadlocks master

2026-09-02 09:00 - <event name="xml_deadlock_report" package="sqlserver" timestamp="2026-09-02T09:00:10.459Z"><data name="xml_report"><value><deadlock><victim-list><vict...

Deadlocks database unknown

2026-09-02 09:00 - <event name="xml_deadlock_report" package="sqlserver" timestamp="2026-09-02T09:00:10.459Z"><data name="xml_report"><type name="xml" package="package0"...

Long running DBAChaos

SPID 0, 71s, wait completed cached query. UPDATE dbo.ChaosLock SET Payload = Payload + 1, ModifiedUtc = SYSUTCDATETIME() WHERE LockId = 3

Growth dbNexia_db

0.0 GB growth (Log ).

Largest DB dbNexia_db

0.4 GB current size.

Largest DB DBAChaos

0.1 GB current size.

Resources CPU and memory

CPU 1.0%, memory free 55.4%, users 1, transactions 7.

TempDB Data and log

Data 11.8%, log 16.8%, version store 0 MB.

Metrics and evidence Signals

Last OK 2026-09-02 10:15, last failed -. 206 runtime events. 9 deadlocks / 0 blocking. 1 long running. 0.0 GB growth.

Recommended action Identify blockers, statements, and transaction order; prioritize indexing or code changes.
Pattern Repeated blocking or deadlocks indicate a transaction, query, or indexing pattern.
Forecast Blocking and deadlock pressure is likely to repeat under the same workload until the blocking pattern is removed.
Break the trend remove blocker/deadlock source; triage latest log errors; tune or reschedule long running requests.
CPU / memory free 1.0% / 55.4%
TempDB data / log 11.8% / 16.8%
Growth now / 7d forecast 0.0 GB / 0.0 GB
Runtime / 24h forecast 206 / 206
Backups / disks / jobs 0 / 0 / 0
Blocking / long queries 9 / 1
Telemetry gaps 0
Largest database 0.4 GB
Operating profile Test
Type SQL Server
Environment Test
Repository size 1.33 GB
Last OK 2026-09-02 10:15
Last failed -
Data quality 100%
Source confidence 0 gaps
AuditLog Available

dbNexia_db.dbo.AuditLog

DbSizes Available

dbNexia_db.dbo.dbsizes

EventLog Available

dbNexia_db.dbo.EventLog

LiveRequests Available

VIEW SERVER STATE permission

MsdbAgent Available

msdb SQL Agent history

MsdbBackup Available

msdb.dbo.backupset

ServerMetrics Available

dbNexia_db.dbo.ServerMetrics

TempDb Available

VIEW SERVER STATE permission

VolumeStats Available

VIEW SERVER STATE permission

Runtime 206 events

Errors 102, timeouts 104, login failures 0, CPU warnings 0, memory grants 0.

(@MinEvidenceTime datetime) CREATE TABLE #SqlBackupLog ( LogDate datetime NULL, ProcessInfo nvarchar(64) NULL, [Text] nvarchar(max) NULL ); DECLAR...

Meaning

database 'Errors 102, timeouts 104, login failures 0, CPU warnings 0, memory grants 0.' needs a newer log backup in the SQL backup chain.

Recommended fix

Run or repair the log-backup job for database 'Errors 102, timeouts 104, login failures 0, CPU warnings 0, memory grants 0.'. If the log still cannot truncate, fix the specific blocker: open transaction, replication/AG send queue, backup target failure, or full-backup chain reset.

Verify

Open Backup History for the database and confirm a newer successful backup row of the missing type appears after the fix.

Backup risks0
BackupsNo risks

No backup risks detected for this server.

Storage0 low volumes
StorageNo low volumes

No low free-space volumes detected for this server.

Growth0.0 GB
dbNexia_db4.0 MB

Log growth inside the selected 24h window.

Meaning and fix

Meaning: This signal is abnormal, but the row text is not specific enough to name a single root cause with confidence.

Fix: Use the row values already shown here to filter the related report by the same server, database/job/login and the same time window.

Verify: The signal should stop repeating in the next collection window after the underlying job, permission, backup, or workload issue is fixed.

Queries and concurrency10 signals
Long running SPID 071s

DBAChaos; wait completed cached query; blocked by -; UPDATE dbo.ChaosLock SET Payload = Payload + 1, ModifiedUtc = SYSUTCDATETIME() WHERE LockId = 3

Meaning and fix

Meaning: A session is waiting because another transaction is holding a lock it needs.

Fix: Open the blocking or long-running detail row, use the shown blocking session and database, then stop the blocking transaction or fix the statement/index that makes it hold locks too long.

Verify: The blocking report should no longer show the same blocking session/database combination, and waiting requests should complete.

Deadlock2026-09-02 09:00

master; <event name="xml_deadlock_report" package="sqlserver" timestamp="2026-09-02T09:00:10.459Z"><data name="xml_report"><value><deadlock><victim-list><vict...

Meaning and fix

Meaning: SQL Server detected two sessions holding resources in conflicting order and chose one session as the deadlock victim.

Fix: Use the deadlock event details to identify the two statements and objects. Add the missing supporting index or change the transaction order so both code paths touch objects in the same order.

Verify: After the change, the same database/object pair should stop producing deadlock events in the selected lookback window.

Deadlock2026-09-02 09:00

database unknown; <event name="xml_deadlock_report" package="sqlserver" timestamp="2026-09-02T09:00:10.459Z"><data name="xml_report"><type name="xml" package="package0"...

Meaning and fix

Meaning: SQL Server detected two sessions holding resources in conflicting order and chose one session as the deadlock victim.

Fix: Use the deadlock event details to identify the two statements and objects. Add the missing supporting index or change the transaction order so both code paths touch objects in the same order.

Verify: After the change, the same database/object pair should stop producing deadlock events in the selected lookback window.

Deadlock2026-09-02 09:00

database unknown; <event name="xml_deadlock_report" package="sqlserver" timestamp="2026-09-02T09:00:10.459Z"><data name="xml_report"><value><deadlock><victim-list><vict...

Meaning and fix

Meaning: SQL Server detected two sessions holding resources in conflicting order and chose one session as the deadlock victim.

Fix: Use the deadlock event details to identify the two statements and objects. Add the missing supporting index or change the transaction order so both code paths touch objects in the same order.

Verify: After the change, the same database/object pair should stop producing deadlock events in the selected lookback window.

Deadlock2026-09-02 03:00

master; <event name="xml_deadlock_report" package="sqlserver" timestamp="2026-09-02T03:00:10.245Z"><data name="xml_report"><value><deadlock><victim-list><vict...

Meaning and fix

Meaning: SQL Server detected two sessions holding resources in conflicting order and chose one session as the deadlock victim.

Fix: Use the deadlock event details to identify the two statements and objects. Add the missing supporting index or change the transaction order so both code paths touch objects in the same order.

Verify: After the change, the same database/object pair should stop producing deadlock events in the selected lookback window.

Deadlock2026-09-02 03:00

database unknown; <event name="xml_deadlock_report" package="sqlserver" timestamp="2026-09-02T03:00:10.245Z"><data name="xml_report"><value><deadlock><victim-list><vict...

Meaning and fix

Meaning: SQL Server detected two sessions holding resources in conflicting order and chose one session as the deadlock victim.

Fix: Use the deadlock event details to identify the two statements and objects. Add the missing supporting index or change the transaction order so both code paths touch objects in the same order.

Verify: After the change, the same database/object pair should stop producing deadlock events in the selected lookback window.

Largest databases and job failures0 job failures
dbNexia_db0.4 GB

Current largest database inventory sample.

DBAChaos0.1 GB

Current largest database inventory sample.

tempdb0.0 GB

Current largest database inventory sample.

JobsNo failures

No SQL Agent job failures detected in this window.