Microsoft SQL Server Operations Guides on Netdata

How Microsoft SQL Server actually works in production: a mental model for operators

Mon, 01 Jan 0001 00:00:00 +0000

How Microsoft SQL Server actually works in production: a mental model for operators

Most SQL Server incidents look confusing because operators bring a Linux-process mental model to a system that is not one. sqlservr (sqlservr.exe on Windows) is a single multi-threaded process, but inside it runs SQLOS, a user-mode operating system with its own scheduler, memory manager, and I/O completion handling. The host OS does not schedule your queries, does not cache your data pages, and does not decide which transaction gets a lock. SQL Server does all of that itself.

Microsoft SQL Server monitoring checklist: the signals every production instance needs

Mon, 01 Jan 0001 00:00:00 +0000

Microsoft SQL Server monitoring checklist: the signals every production instance needs

Most SQL Server outages are not exotic. The transaction log fills because a backup job silently stopped. A sleeping session with an open transaction blocks forty other sessions until the worker pool runs dry. TempDB runs out of space and every database on the instance stalls at once. All of these are visible hours or days in advance if you collect the right signals. Most teams do not.

Microsoft SQL Server monitoring maturity model: from survival to expert

Mon, 01 Jan 0001 00:00:00 +0000

Microsoft SQL Server monitoring maturity model: from survival to expert

Most SQL Server outages are not exotic. The transaction log fills because nobody noticed log backups stopped. A head blocker sits idle with an open transaction while the worker thread pool drains. Error 825 appears in the error log for weeks before the disk actually fails. In each case, the signal was available; the monitoring just was not looking at it.

SQL Server AG send and redo queues growing: replication lag and failover RTO

Mon, 01 Jan 0001 00:00:00 +0000

SQL Server AG send and redo queues growing: replication lag and failover RTO

Two queues decide whether your Always On Availability Group can actually fail over: the send queue (log generated on the primary but not yet shipped to the secondary) and the redo queue (log received by the secondary but not yet replayed). When either grows without bound, replication lag is the visible symptom, but the hidden cost is failover RTO. On forced or automatic failover, the new primary must drain the entire redo queue before it accepts writes, so a queue that looks tolerable during steady state can turn a 30-second failover into a 30-minute one.

SQL Server AlwaysOn failover readiness: quorum, health checks, and the failover you assume works

Mon, 01 Jan 0001 00:00:00 +0000

SQL Server AlwaysOn failover readiness: quorum, health checks, and the failover you assume works

An AG that reports “healthy” in the dashboard can still fail to failover when you need it. The synchronization state tells you data is flowing between replicas. It says nothing about whether the cluster can orchestrate a failover, whether the health detection policy will catch the specific failure you are about to have, or whether the cluster has already exhausted its automatic failover budget for the period.

SQL Server Availability Group not synchronizing: NOT_HEALTHY replicas and failover risk

Mon, 01 Jan 0001 00:00:00 +0000

SQL Server Availability Group not synchronizing: NOT_HEALTHY replicas and failover risk

The symptom arrives as an alert or a dashboard color change: a synchronous-commit secondary replica is reporting synchronization_health_desc = NOT_HEALTHY or connected_state_desc = DISCONNECTED in sys.dm_hadr_availability_replica_states. The primary is still accepting writes, but the protection you assumed is degraded or gone.

In synchronous-commit mode, the primary waits for the secondary to harden log records before acknowledging commits. When the secondary drops or stops keeping up, the primary either continues unprotected or stops accepting writes entirely, depending on required_synchronized_secondaries_to_commit. Either way, your recovery point objective and your recovery time objective are both at risk.

SQL Server backup freshness: the recovery point you only discover you lack during an incident

Mon, 01 Jan 0001 00:00:00 +0000

SQL Server backup freshness: the recovery point you only discover you lack during an incident

The recovery point you actually have is the recovery point you can restore to, not the one your schedule promises. Backup freshness is the gap between those two, measured as the time since the last successful full, differential, and transaction log backup per database. When that gap is wrong, you find out during restore: either an analyst files a ticket for missing data, or an incident forces point-in-time recovery and the chain breaks.

SQL Server blocking chains: finding the head blocker before workers run out

Mon, 01 Jan 0001 00:00:00 +0000

SQL Server blocking chains: finding the head blocker before workers run out

SQL Server is unresponsive. CPU and I/O counters are low. Connections succeed but queries hang. Timeouts and login failures follow. This is the shape of a blocking chain that has crossed into worker-thread exhaustion.

One session holds a lock. Conflicting sessions queue behind it, each waiting on an LCK_M_* wait and each pinning a worker from SQL Server’s fixed-size pool. As the chain deepens, the worker pool drains. Once exhausted, new requests get THREADPOOL waits and the instance appears down to applications, even though the OS shows sqlservr healthy and storage idle.

SQL Server buffer cache hit ratio low: when the working set no longer fits in memory

Mon, 01 Jan 0001 00:00:00 +0000

SQL Server buffer cache hit ratio low: when the working set no longer fits in memory

A low buffer cache hit ratio (BCHR) gets two reactions in production: teams page on-call for a single dip during a maintenance window, or they ignore a sustained decline because the counter is “unreliable.” Both are wrong. BCHR is a weak signal alone, but paired with Page Life Expectancy (PLE), PAGEIOLATCH_* waits, and workload context, it tells you whether your working set still fits in the buffer pool.

SQL Server CPU utilization high: telling query load apart from a bad plan

Mon, 01 Jan 0001 00:00:00 +0000

SQL Server CPU utilization high: telling query load apart from a bad plan

Your monitoring says the SQL Server host is at 98% CPU. Before you page anyone or start killing sessions: SQL Server is designed to use available CPU. A cold buffer pool after restart, backup compression, an ETL window, or a well-parallelized reporting query will all legitimately pin CPU at 90%+. High CPU is a symptom with no severity attached until you answer two questions: who is burning the CPU (SQL Server or something else on the host), and is the work useful (throughput) or wasted (a bad plan, a compilation storm, or spinlock contention).

SQL Server CXPACKET and CXCONSUMER waits: parallelism, MAXDOP, and what is actually wrong

Mon, 01 Jan 0001 00:00:00 +0000

SQL Server CXPACKET and CXCONSUMER waits: parallelism, MAXDOP, and what is actually wrong

You opened sys.dm_os_wait_stats, excluded the idle noise, and CXPACKET is sitting at the top consuming 40, 50, maybe 70 percent of total wait time. The first search result tells you parallelism is out of control. The second tells you to set MAXDOP to 1. Both are usually wrong.

CXPACKET is routinely the number one wait on healthy systems. Its presence alone means parallel queries are running, and parallel threads spend much of their existence waiting for each other. The wait is a side effect of work being done in parallel, not the disease. The real questions are whether that parallel work is skewed, whether the queries going parallel should be parallel at all, and whether the engine is burning worker threads and CPU on plans that would be faster serial.

SQL Server database in SUSPECT or RECOVERY_PENDING: an offline database and how to recover it

Mon, 01 Jan 0001 00:00:00 +0000

SQL Server database in SUSPECT or RECOVERY_PENDING: an offline database and how to recover it

A production database is showing state_desc = SUSPECT or RECOVERY_PENDING in sys.databases. Applications cannot open connections to that database. Users are seeing login failures, query timeouts, or generic “database cannot be opened” errors. The SQL Server instance itself is up, and every other database on it may be fine.

RECOVERY_PENDING rarely means corruption. It usually means SQL Server could not get the resources it needed during recovery: a missing file, a full log volume, a permissions change, or a transient I/O failure at startup. SUSPECT is more serious because recovery actually ran and failed, but it still does not automatically mean data loss. The wrong move is to jump straight to DBCC CHECKDB with REPAIR_ALLOW_DATA_LOSS. The right move is to fix the underlying resource, re-run recovery, and only fall back to repair or restore when that fails.

SQL Server Error 1205: transaction was deadlocked and chosen as the deadlock victim

Mon, 01 Jan 0001 00:00:00 +0000

SQL Server Error 1205: transaction was deadlocked and chosen as the deadlock victim

The error text returned to the client is explicit:

Transaction (Process ID %d) was deadlocked on %.*ls resources with another process and has been chosen as the deadlock victim. Rerun the transaction.

%d is the SPID. %.*ls names the resource type, typically lock. The message tells the application to rerun the transaction but not why the deadlock happened, which resource was contended, or which other session was involved. To answer those questions you need the deadlock graph.

SQL Server Error 18456: login failed for user, and what the state code means

Mon, 01 Jan 0001 00:00:00 +0000

SQL Server Error 18456 is the universal “Login failed for user X” message. It is deliberately vague: every client, from sqlcmd to the application’s connection pool, sees the same string with severity 14 and state 1. The client never learns whether the password was wrong, the login does not exist, the database is offline, or the account is disabled. That information lives only in the SQL Server error log, encoded as a state code.

SQL Server Error 701: there is insufficient system memory to run this query

Mon, 01 Jan 0001 00:00:00 +0000

Error 701 is one of SQL Server’s bluntest messages: “There is insufficient system memory in resource pool ‘default’ to run this query.” When it fires, the engine could not satisfy an allocation. Queries that were running fine seconds ago start failing, and the failure cascades into application timeouts, retry storms, and a flood of related errors (17890, 8645).

The error itself tells you very little. It does not say whether the buffer pool is starved, whether a single query is hoarding a memory grant, whether an Extended Events ring buffer has eaten 50 GB, or whether the OS is reclaiming memory from a VM balloon driver. Investigate by source.

SQL Server Error 823 and 824: I/O and logical consistency errors

Mon, 01 Jan 0001 00:00:00 +0000

Errors 823 and 824 are SQL Server’s severity-24 storage integrity alarms. 823 means the operating system reported a hard failure on a file API call. 824 means the call succeeded but the page failed an internal integrity check. Both are PAGE-worthy the moment they appear; they do not self-resolve, and continued use of the affected files risks losing data that was fine minutes earlier.

Error 825 is the soft warning that usually precedes both: SQL Server retried a read that initially failed and eventually succeeded. The query did not fail and no connection was killed, which is why most teams do not alert on it. It is also the most reliable predictor that an 823 or 824 is coming.

SQL Server Error 825: read-retry succeeded and the disk is failing

Mon, 01 Jan 0001 00:00:00 +0000

SQL Server Error 825: read-retry succeeded and the disk is failing

Error 825 is what SQL Server writes to the error log when a disk read failed on the first attempt but succeeded on a retry (attempt 2, 3, or 4). The query completes. The application sees no failure. But the storage underneath just told you it is failing.

Most monitoring setups never surface Error 825. It is a severity-10 informational message, and typical SQL Server Agent alert configurations target severity 19 and above. The error sits quietly in the log until something harder arrives: an 823 (hard I/O error) or an 824 (logical consistency error). By then the page may already be unreadable.

SQL Server Error 9002: the transaction log for the database is full

Mon, 01 Jan 0001 00:00:00 +0000

SQL Server Error 9002: the transaction log for the database is full

Your application is throwing write failures and the SQL Server error log shows: “The transaction log for database ‘X’ is full due to ‘LOG_BACKUP’” (or ACTIVE_TRANSACTION, AVAILABILITY_REPLICA, REPLICATION, or another reason in quotes). Every INSERT, UPDATE, and DELETE against that database now fails with error 9002. Read-only queries may still work, which makes the outage look confusingly partial from the outside.

SQL Server failed login storm: brute force, credential drift, and service-account failures

Mon, 01 Jan 0001 00:00:00 +0000

A failed-login storm fills ERRORLOG with “Login failed for user” entries (Error 18456). Counting them is the first instinct and the wrong one. Aggregate rate cannot tell brute force from a batch job running on rotated secrets, a service account whose password just expired, an application pool recycling, or a SQL Server 2025 replication secondary emitting benign noise every few minutes.

SQL Server HADR_SYNC_COMMIT waits: a synchronous secondary throttling primary commits

Mon, 01 Jan 0001 00:00:00 +0000

SQL Server HADR_SYNC_COMMIT waits: a synchronous secondary throttling primary commits

HADR_SYNC_COMMIT at the top of your wait statistics is a counterintuitive failure. The primary replica looks idle: CPU is low, local I/O is fast, batch requests look normal. Yet every write transaction stalls. The cause is not on the primary but on the synchronous secondary, the network between replicas, or the AG transport itself.

In synchronous-commit mode, the primary cannot acknowledge a transaction commit until the secondary hardens the log record to disk. Every write transaction pays that round-trip tax. When the secondary or the path to it degrades, that tax becomes seconds of latency per commit. Under sustained write load, the delays lengthen lock hold times on the primary and cascade into blocking, worker thread growth, and eventually THREADPOOL waits. The application experiences this as a general slowdown, but the root cause is a single replica that cannot keep up.

SQL Server high compilations per second: plan cache pollution and CPU burn

Mon, 01 Jan 0001 00:00:00 +0000

SQL Server high compilations per second: plan cache pollution and CPU burn

SQL Compilations/sec is climbing, CPU is pinned, and the application is reporting latency even though storage and locking look clean. Nothing is “broken” in the error log, but the engine is spending a large share of its CPU budget turning query text into execution plans instead of executing them.

Compilation is expensive. Every new plan costs parse, optimization, and often a compile-time memory grant. When the ratio of SQL Compilations/sec to Batch Requests/sec climbs past roughly 10%, the plan cache is failing to do its job. Sustained above 20% with CPU pressure, you have an active problem.

SQL Server high recompilations: stale statistics and schema changes churning plans

Mon, 01 Jan 0001 00:00:00 +0000

SQL Server high recompilations: stale statistics and schema changes churning plans

CPU is climbing, SOS_SCHEDULER_YIELD is creeping up, batch requests look normal, and your top waits are not obviously I/O or lock related. Check the SQL Statistics counters: if SQL Re-Compilations/sec is running well above 10% of SQL Compilations/sec, you have a plan stability problem, not a plan cache efficiency problem.

Recompilations are not the same as first-time compilations. First-time compilations (or recompilations forced by plan cache eviction under memory pressure) belong in SQL Server high compilations per second. Recompilations mean SQL Server had a cached plan, decided it could no longer trust it, and spent CPU rebuilding it. Each recompile is CPU work, and if the recompiling statement sits inside a multi-statement batch or stored procedure, the cost cascades across dependent statements.

SQL Server high VLF count: transaction log fragmentation that slows recovery

Mon, 01 Jan 0001 00:00:00 +0000

SQL Server high VLF count: transaction log fragmentation that slows recovery

A database restarts and takes 45 minutes to come back ONLINE. An AlwaysOn failover completes in seconds, but the new primary sits in RECOVERING for an hour while the redo queue drains. The error log shows nothing obviously wrong: no 823 or 824, no corruption, no missing files. CPU and I/O during recovery look modest, just stretched out. Users escalate.

SQL Server I/O stall high: per-file storage latency from dm_io_virtual_file_stats

Mon, 01 Jan 0001 00:00:00 +0000

SQL Server I/O stall high: per-file storage latency from dm_io_virtual_file_stats

When PAGEIOLATCH_* or WRITELOG climbs to the top of sys.dm_os_wait_stats, the question is whether storage is the bottleneck or whether SQL Server is doing too much physical I/O because the buffer pool is undersized. sys.dm_io_virtual_file_stats(NULL, NULL) is the only DMV that answers this at file granularity from inside the engine.

The values it returns are cumulative since the SQL Server service last started, so a single snapshot is almost useless. Compute deltas over a short window (15-60 seconds during the incident) and divide stall time by operation count to get current per-file latency. Lifetime averages on a long-running instance hide the bad minutes that matter.

SQL Server instance down: no response on port 1433 and where to look first

Mon, 01 Jan 0001 00:00:00 +0000

SQL Server instance down: no response on port 1433 and where to look first

Your availability probe just fired: TCP connect plus SELECT 1 against port 1433 has failed three or more times over at least 60 seconds. Before you restart anything, separate the two failure modes that get lumped together as “SQL Server is down”. They have different causes, different fixes, and different blast radii.

Mode one: no TCP connect at all. The listener is not accepting connections on 1433 (or the named instance’s dynamic port). The service is stopped, the host is down, the network path is broken, or the listener is misconfigured, commonly after an AlwaysOn failover. The engine is not there to talk to.

SQL Server LCK_M waits high: lock contention and what the suffixes mean

Mon, 01 Jan 0001 00:00:00 +0000

SQL Server LCK_M waits high: lock contention and what the suffixes mean

When LCK_M_* wait types dominate sys.dm_os_wait_stats, worker threads are suspended waiting for locks instead of doing work. The prefix is uniform; the suffix is the lock mode the waiter requested, and it is the diagnostic signal. LCK_M_S means a reader is blocked. LCK_M_IX means an intent-exclusive writer is queued behind a conflicting holder. LCK_M_SCH_M is a DDL operation waiting on schema modification. The mode narrows the suspect list immediately.

SQL Server lock escalation: when row locks become a table lock and block everyone

Mon, 01 Jan 0001 00:00:00 +0000

SQL Server lock escalation: when row locks become a table lock and block everyone

A batch UPDATE or DELETE runs longer than usual. CPU looks fine, I/O looks fine, and then dozens of sessions start waiting on LCK_M_* waits, all blocked by the batch session. By the time you log in, the worker thread pool is draining and the instance is heading toward THREADPOOL. The root cause is not a hung transaction or a resource bottleneck. It is lock escalation: SQL Server traded thousands of row locks for a single table lock, and every other session that wants to touch that table is now serialized behind it.

SQL Server log autogrow stall: why every write pauses while the log file grows

Mon, 01 Jan 0001 00:00:00 +0000

SQL Server log autogrow stall: why every write pauses while the log file grows

Applications report periodic, mysterious write stalls. Throughput drops briefly, then recovers. Repeat. The transaction log on the affected database is creeping upward, and there are no alarms on disk space. What you are seeing is almost certainly log autogrow stall: every write transaction in the database pauses while SQL Server expands and zero-initializes the transaction log file.

SQL Server log backups missing: the full-recovery log that grows forever

Mon, 01 Jan 0001 00:00:00 +0000

SQL Server log backups missing: the full-recovery log that grows forever

The application starts throwing write errors. The database is online, reads work, but every INSERT, UPDATE, and DELETE fails with error 9002: the transaction log is full. The log volume is at zero free space, or the log file has auto-grown to many times the size of the data files. When you ask when the last log backup ran, nobody knows.

SQL Server log_reuse_wait_desc: why the transaction log will not truncate

Mon, 01 Jan 0001 00:00:00 +0000

SQL Server log_reuse_wait_desc: why the transaction log will not truncate

The database is throwing error 9002, writes are failing, the log file has eaten the volume, and someone is about to add another log file or shrink the existing one. Before anyone touches file sizes, run one query:

SELECT name, recovery_model_desc, log_reuse_wait_desc
FROM sys.databases;

That third column is the root-cause field most teams skip. It tells you why log truncation could not clear any Virtual Log Files (VLFs) the last time SQL Server tried. Every fix for a full log flows from this value. Adding disk space without reading it treats the symptom: the log fills again, usually within hours, and now you also have VLF fragmentation to deal with.

SQL Server max server memory: setting it so the OS and buffer pool both survive

Mon, 01 Jan 0001 00:00:00 +0000

SQL Server max server memory: setting it so the OS and buffer pool both survive

SQL Server is built to consume memory until something stops it. On a dedicated box with no cap, the engine will eat nearly all physical RAM for the buffer pool and keep going until the OS pushes back. That is not a leak; it is the design. max server memory is the one knob that turns that behavior into something safe to run next to other processes.

SQL Server Memory Grants Pending above zero: queries queued before they can run

Mon, 01 Jan 0001 00:00:00 +0000

SQL Server Memory Grants Pending above zero: queries queued before they can run

Memory Grants Pending is a SQLServer:Memory Manager counter that should almost always be zero. When it rises above zero, queries are fully parsed and optimized but cannot start execution because the query workspace memory pool is exhausted. Applications see queries that appear hung: connections stay open, latency climbs, and CPU and I/O may look idle.

The counter pairs with the RESOURCE_SEMAPHORE wait type. The counter shows how many queries are queued right now. The wait type aggregates how long they spent in that queue. Both point at the same bottleneck: SQL Server cannot honor a memory grant request because the workspace memory pool has been drained by other queries, by one oversized grant from a bad plan, or by external OS pressure on max server memory.

SQL Server memory pressure spiral: PLE collapse, physical reads, and I/O saturation

Mon, 01 Jan 0001 00:00:00 +0000

SQL Server memory pressure spiral: PLE collapse, physical reads, and I/O saturation

The signature of a memory pressure spiral is a rapid Page Life Expectancy (PLE) drop combined with rising PAGEIOLATCH_* waits and increasing I/O stall on data files. CPU sits low to moderate because the bottleneck is not compute. It is the buffer pool being drained, which forces physical reads, which saturate the storage path, which makes every query slower, which piles up more concurrent sessions, which pressures memory further.

SQL Server Page Life Expectancy dropping: the buffer pool under memory pressure

Mon, 01 Jan 0001 00:00:00 +0000

SQL Server Page Life Expectancy dropping: the buffer pool under memory pressure

Page Life Expectancy (PLE) measures the expected seconds a data page stays in the buffer pool before eviction. A sharp drop means the lazy writer is flushing pages faster than the workload can reuse them, and queries that previously hit cache now trigger physical reads.

The signature of a real pressure event is a 50%+ drop from baseline coinciding with rising PAGEIOLATCH_* waits and a falling buffer cache hit ratio. The old “300 seconds” rule is obsolete: it was calibrated for 32-bit servers with ~4GB buffer pools. On a modern instance with 256GB of memory, PLE above 100,000 seconds is normal, and 300 seconds would be a crisis.

SQL Server PAGEIOLATCH waits: the buffer pool waiting on slow storage

Mon, 01 Jan 0001 00:00:00 +0000

SQL Server PAGEIOLATCH waits: the buffer pool waiting on slow storage

Your top wait type is PAGEIOLATCH_SH or PAGEIOLATCH_EX. Queries that used to be sub-50ms now take seconds. CPU may be low. There are no blocking chains. The buffer pool is waiting on disk.

PAGEIOLATCH waits are the direct fingerprint of physical I/O. A worker needs an 8KB data page that is not in the buffer pool, takes an in-memory latch on the buffer descriptor, and waits for storage to return the page. When the read completes, the worker continues. Sustained PAGEIOLATCH time means the engine is spending wall-clock time waiting on disk.

SQL Server parameter sniffing: a good plan for one value, catastrophic for the next

Mon, 01 Jan 0001 00:00:00 +0000

SQL Server parameter sniffing: a good plan for one value, catastrophic for the next

A stored procedure that ran in 30 ms for weeks is now taking 8 seconds per call. Query text unchanged. Indexes unchanged. Statistics look fine. The application is timing out. The same query with literal values returns instantly. With OPTION (RECOMPILE) appended, it returns instantly. The cached plan is the problem.

This is parameter sniffing. The optimizer compiled the plan for the parameter values it saw first, cached the result, and every subsequent call reuses a plan that is wrong for the values it is now processing. On a table with skewed data, a plan sized for 12 rows is catastrophic when fed 12 million.

SQL Server plan cache bloat: single-use ad-hoc plans wasting memory

Mon, 01 Jan 0001 00:00:00 +0000

SQL Server plan cache bloat: single-use ad-hoc plans wasting memory

SQL Server plan cache bloat from single-use ad-hoc plans is a slow degradation. Queries return correct results. The instance stays up. But memory that should cache hot data pages holds thousands of compiled plans that will never execute again. Operators typically discover it when PLE drifts down for no obvious reason, when buffer cache hit ratio slips, or when compilations per second stays elevated relative to batch requests. By the time it surfaces in user-facing latency, the plan cache has been stealing buffer pool memory for weeks.

SQL Server RESOURCE_SEMAPHORE waits: queries stuck waiting for a memory grant

Mon, 01 Jan 0001 00:00:00 +0000

SQL Server RESOURCE_SEMAPHORE waits: queries stuck waiting for a memory grant

RESOURCE_SEMAPHORE is the wait type SQL Server records when a worker thread cannot get a query memory grant. Before a query runs a sort, hash, or certain joins, the optimizer estimates how much workspace memory it needs and asks the grant pool for it. When the pool is exhausted, parsed-and-optimized queries sit in a queue. To the application they look hung.

SQL Server restore readiness: why a backup you never test is not a backup

Mon, 01 Jan 0001 00:00:00 +0000

SQL Server restore readiness: why a backup you never test is not a backup

The most common SQL Server backup monitoring answers one question: did the job succeed? A green checkmark means SQL Server wrote bytes to a file. It does not mean those bytes can be read back, decrypted, applied through a recovery sequence, and brought online within your RTO.

The gap between “backup succeeded” and “we can recover” is where most DR failures actually live. Backups fail to restore because of media corruption the backup job never validated, because a TDE or backup-encryption certificate was not backed up alongside the data, because an ad-hoc operation broke the log chain and silently invalidated hours of log backups, or because the restore takes four times longer than anyone measured. None of those surface in backup-completion monitoring.

SQL Server runnable tasks backlog: the in-engine CPU queue OS metrics miss

Mon, 01 Jan 0001 00:00:00 +0000

SQL Server runnable tasks backlog: the in-engine CPU queue OS metrics miss

Your monitoring says the host is at 45% CPU. Users say the database is slow. Both are right, because SQL Server does not use the OS scheduler for query execution. It runs its own cooperative scheduling layer, SQLOS, with one scheduler per logical CPU, its own run queues, and its own worker thread pool. OS CPU percent measures what the host kernel sees. It does not see tasks sitting in SQLOS queues waiting for a scheduler slot, and on virtualized hosts it does not see time the hypervisor stole from the guest.

SQL Server sleeping head blocker: the idle session holding a lock and an open transaction

Mon, 01 Jan 0001 00:00:00 +0000

SQL Server sleeping head blocker: the idle session holding a lock and an open transaction

The most dangerous blocking shape in SQL Server does not look active. Sessions pile up behind a head blocker, batch requests stall, and transactions per second drop. CPU and I/O are idle. The engine looks healthy on resource metrics, but queries are timing out.

When you query sys.dm_exec_requests for the blocker, you find nothing. The session_id that everyone is waiting on does not appear in the requests DMV because the head blocker has no active request. It is sleeping. It is, however, holding locks under an open transaction that never committed, never rolled back, and never will on its own.

SQL Server SOS_SCHEDULER_YIELD waits: CPU scheduler pressure explained

Mon, 01 Jan 0001 00:00:00 +0000

SQL Server SOS_SCHEDULER_YIELD waits: CPU scheduler pressure explained

When SOS_SCHEDULER_YIELD dominates sys.dm_os_wait_stats, the reflex is to assume CPU pressure and start hunting for bad queries. That reflex is right about half the time. The other half, you are chasing a signal that is doing exactly what it was designed to do: recording every time a worker voluntarily yielded its 4ms quantum because other runnable workers were queued.

The wait type has existed in SQL Server since the SQLOS era and the 4ms quantum is fixed in every version. It cannot be tuned. What you can tune is your interpretation. A workload doing efficient set-based scans of pages already in memory will yield constantly and rack up enormous SOS_SCHEDULER_YIELD numbers without anything being wrong. A VM on an oversubscribed host reports the same wait type while the hypervisor silently steals CPU cycles SQL Server cannot see.

SQL Server suspect_pages: the durable record of storage corruption

Mon, 01 Jan 0001 00:00:00 +0000

SQL Server suspect_pages: the durable record of storage corruption

The SQL Server error log recycles on every service restart, and by default only six archived logs are retained. When a storage fault produces errors 823, 824, or torn-page detection, the entries that document it may be gone before anyone investigates. msdb.dbo.suspect_pages is where those events also land, and unlike the error log it survives restarts. Treat it as the durable forensic record of page-level I/O corruption on the instance.

SQL Server TDE and endpoint certificate expiry: silent AG and backup failures

Mon, 01 Jan 0001 00:00:00 +0000

SQL Server does not alert when a certificate is about to expire. There is no performance counter, no error log entry at expiry time, and no DMV flag that flips the moment the date passes. The engine keeps using the certificate silently until something forces a re-evaluation, and at that point the failure mode depends entirely on what the certificate was protecting.

Three consumers of the same self-signed certificate pattern behave in three different ways:

SQL Server TempDB file configuration: one data file per CPU and why it matters

Mon, 01 Jan 0001 00:00:00 +0000

SQL Server TempDB file configuration: one data file per CPU and why it matters

TempDB is the shared scratchpad every database on a SQL Server instance writes to. Temp tables, table variables, sort and hash spills, row version stores for RCSI and AlwaysOn readable secondaries, and internal worktables all land here. When TempDB serializes, every database on the instance serializes with it. The most common serialization point is not space or I/O. It is logical latch contention on a handful of allocation bitmap pages.

SQL Server TempDB full: the shared scratch database that halts every query

Mon, 01 Jan 0001 00:00:00 +0000

SQL Server TempDB full: the shared scratch database that halts every query

Applications start failing with error 1105 (“could not allocate space for object in database ’tempdb’ because the ‘PRIMARY’ filegroup is full”) or error 3958, and the failures are not limited to one database. Every query on the instance that needs a temp table, a sort or hash spill, a worktable, or a row version touches TempDB. When TempDB cannot allocate space, all of them fail at once.

SQL Server TempDB PAGELATCH contention: allocation page latch waits on PFS, GAM, and SGAM

Mon, 01 Jan 0001 00:00:00 +0000

SQL Server TempDB PAGELATCH contention: allocation page latch waits on PFS, GAM, and SGAM

CPU is moderate, I/O latency is normal, the buffer pool is healthy, and throughput has dropped. Wait statistics show PAGELATCH_UP or PAGELATCH_EX dominating, and sys.dm_os_waiting_tasks shows sessions waiting on pages like 2:1:1, 2:1:2, or 2:1:3.

This is TempDB allocation page latch contention. Every temp table, spilled sort, or worktable allocation needs space in TempDB. SQL Server tracks free space and allocation state in bitmap pages: PFS (Page Free Space), GAM (Global Allocation Map), and SGAM (Shared Global Allocation Map). When sessions contend for the same allocation pages, they serialize on in-memory latches. Disk and CPU are not the bottleneck. The problem is logical contention on a fixed set of pages in the buffer pool.

SQL Server TempDB version store growth: long transactions under RCSI and snapshot isolation

Mon, 01 Jan 0001 00:00:00 +0000

SQL Server TempDB version store growth: long transactions under RCSI and snapshot isolation

TempDB is filling and the version store is the consumer. You query tempdb.sys.dm_db_file_space_usage and version_store_reserved_page_count dominates the page budget, often after enabling Read Committed Snapshot Isolation (RCSI) or snapshot isolation, after turning a secondary replica into a readable one, or during an online index operation. Queries that depend on TempDB (sorts, hashes, temp tables, even row-versioned reads on secondaries) stall or fail when the volume runs out.

SQL Server THREADPOOL waits: worker thread exhaustion and refused connections

Mon, 01 Jan 0001 00:00:00 +0000

SQL Server THREADPOOL waits: worker thread exhaustion and refused connections

Your monitoring says the SQL Server host is fine: CPU at 15%, disk latency normal, memory steady. But the application is timing out, new connections hang, and the instance might as well be down. When you finally get in, the wait stats tell the story: THREADPOOL.

THREADPOOL means every worker thread in the SQLOS pool is busy, and new requests are queuing for a thread that does not exist. From the client’s perspective this is equivalent to connection refusal. The server is not slow. It is not accepting work at all.

SQL Server transaction log percent used climbing toward full

Mon, 01 Jan 0001 00:00:00 +0000

SQL Server transaction log percent used climbing toward full

The Percent Log Used counter on one of your databases is climbing and it is not coming back down. This is the leading gauge before Error 9002 (“The transaction log for database ‘X’ is full”), at which point every write against that database fails. Reads may still work, which makes the outage look strange from the application side: queries succeed, inserts and updates throw errors.

SQL Server user connections climbing: connection pool leaks and retry storms

Mon, 01 Jan 0001 00:00:00 +0000

SQL Server user connections climbing: connection pool leaks and retry storms

A rising User Connections counter is easy to misread. It does not mean that many queries are running. Most application connections are pooled and idle, so the count can climb for hours while CPU, I/O, and batch rate look almost normal.

The useful split is shape and correlation. A slow upward trend without a matching rise in Batch Requests/sec usually points to an application-tier connection pool leak or pool fragmentation. A sudden spike, especially after transient errors, points to a retry storm or a burst of new application instances. The dangerous endpoint is the same: enough concurrent active work consumes worker threads until new requests queue on THREADPOOL, which is effectively connection refusal.

SQL Server wait statistics: reading sys.dm_os_wait_stats to find the real bottleneck

Mon, 01 Jan 0001 00:00:00 +0000

SQL Server wait statistics: reading sys.dm_os_wait_stats to find the real bottleneck

Every time a SQL Server worker thread cannot proceed, the engine records what it was waiting for and for how long. The cumulative result lives in sys.dm_os_wait_stats. When users say “the database is slow” and CPU, memory, and disk all look acceptable, wait statistics are usually where the answer is.

The catch: the DMV is a cumulative counter since instance startup, it contains dozens of benign background waits that drown out the signal, and it tells you what the engine waited on, not which query did the waiting. Read it naively and you will chase the wrong bottleneck. Read it correctly and it decomposes performance into exactly which subsystem is contended.

SQL Server worker thread exhaustion: when the instance stops accepting work

Mon, 01 Jan 0001 00:00:00 +0000

SQL Server worker thread exhaustion: when the instance stops accepting work

The application reports that the database is down. CPU is low, disk I/O is low, memory looks fine, the sqlservr process is running. A TCP connection to port 1433 even succeeds. But queries hang, logins time out, and nothing completes. The instance is alive and refusing to work.

This is worker thread exhaustion. Every active request in SQL Server needs a worker thread from a bounded pool. When every worker is occupied, usually suspended waiting on something, new requests cannot be scheduled at all. They queue on the THREADPOOL wait, which from the client’s perspective is indistinguishable from the server being down.

SQL Server WRITELOG waits: commit latency from a slow transaction log

Mon, 01 Jan 0001 00:00:00 +0000

SQL Server WRITELOG waits: commit latency from a slow transaction log

WRITELOG is the wait type SQL Server records when a worker thread blocks on a transaction log flush. Write-ahead logging requires the log block to be hardened to disk before the engine acknowledges a commit, so WRITELOG directly bounds write throughput. When it dominates your top-waits list, every write transaction is paying a latency tax at commit.

The reported symptom is rarely “WRITELOG is high.” It is commit latency, write transaction timeouts, application retry storms, Availability Group replication lag, or batch requests/sec collapsing while CPU sits low. WRITELOG is the in-engine signature you find in sys.dm_os_wait_stats or sys.dm_exec_session_wait_stats. It tells you the bottleneck is in the log write path: the storage below the log file, the I/O stack between SQL Server and that storage, or the commit rate the Log Writer is being asked to service. Tuning queries will not fix it.