https://www.netdata.cloud/tags/microsoft-sql-server/Recent content in Microsoft SQL Server on NetdataHugoen-usSat, 22 Aug 2026 05:09:03 +0300https://www.netdata.cloud/resources/best-sql-server-monitoring-tools/Wed, 12 Aug 2026 00:00:00 +0000https://www.netdata.cloud/resources/best-sql-server-monitoring-tools/https://www.netdata.cloud/solutions/technologies/windows-monitoring/Thu, 18 Dec 2025 00:00:00 +0000https://www.netdata.cloud/solutions/technologies/windows-monitoring/Transform Windows Server monitoring with Netdata&rsquo;s edge-native platform. Get per-second visibility, automatic discovery, and AI-powered troubleshooting at a fraction of traditional costs.https://www.netdata.cloud/monitoring-101/mssql-monitoring/Mon, 01 Jan 0001 00:00:00 +0000https://www.netdata.cloud/monitoring-101/mssql-monitoring/<h2 id="microsoft-sql-server">Microsoft SQL Server</h2> <p><a href="https://en.wikipedia.org/wiki/Microsoft_SQL_Server">Microsoft SQL Server</a> is a relational database management system (RDBMS) developed by Microsoft. It is a software product that stores and retrieves data as requested by other software applications. <a href="https://www.microsoft.com/en-us/sql-server/sql-server-downloads">It can run on various platforms, such as Windows, Linux, and Azure</a>.</p> <h2 id="monitoring-microsoft-sql-server">Monitoring Microsoft SQL Server</h2> <p>To holistically monitor Microsoft SQL Server, you need to track various aspects of its performance, health, and availability. Some of the key metrics to monitor include system level metrics about the impact of SQL Server such as:</p>https://www.netdata.cloud/guides/microsoft-sql-server/microsoft-sql-server-monitoring-checklist/Mon, 01 Jan 0001 00:00:00 +0000https://www.netdata.cloud/guides/microsoft-sql-server/microsoft-sql-server-monitoring-checklist/<p>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.</p> <p>This checklist is the minimum set of signals a production SQL Server instance needs, organized so you can audit what you have today and fill the gaps. It targets standalone instances, failover cluster instances, and AlwaysOn AG deployments on-premises or on VMs. Azure SQL Database and Managed Instance share many of the same DMVs but abstract storage and resource governance differently.</p>https://www.netdata.cloud/guides/microsoft-sql-server/Mon, 01 Jan 0001 00:00:00 +0000https://www.netdata.cloud/guides/microsoft-sql-server/How SQL Server actually fails in production, what the early warning signals look like, and the runbooks for the symptoms you&rsquo;ll see in real incidents.https://www.netdata.cloud/guides/microsoft-sql-server/microsoft-sql-server-ag-send-redo-queue-growing/Mon, 01 Jan 0001 00:00:00 +0000https://www.netdata.cloud/guides/microsoft-sql-server/microsoft-sql-server-ag-send-redo-queue-growing/<p>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.</p>https://www.netdata.cloud/guides/microsoft-sql-server/microsoft-sql-server-ag-not-synchronizing/Mon, 01 Jan 0001 00:00:00 +0000https://www.netdata.cloud/guides/microsoft-sql-server/microsoft-sql-server-ag-not-synchronizing/<p>The symptom arrives as an alert or a dashboard color change: a synchronous-commit secondary replica is reporting <code>synchronization_health_desc = NOT_HEALTHY</code> or <code>connected_state_desc = DISCONNECTED</code> in <code>sys.dm_hadr_availability_replica_states</code>. The primary is still accepting writes, but the protection you assumed is degraded or gone.</p> <p>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 <code>required_synchronized_secondaries_to_commit</code>. Either way, your recovery point objective and your recovery time objective are both at risk.</p>https://www.netdata.cloud/guides/microsoft-sql-server/microsoft-sql-server-backup-freshness/Mon, 01 Jan 0001 00:00:00 +0000https://www.netdata.cloud/guides/microsoft-sql-server/microsoft-sql-server-backup-freshness/<p>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.</p>https://www.netdata.cloud/guides/microsoft-sql-server/microsoft-sql-server-blocking-chain/Mon, 01 Jan 0001 00:00:00 +0000https://www.netdata.cloud/guides/microsoft-sql-server/microsoft-sql-server-blocking-chain/<p>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.</p> <p>One session holds a lock. Conflicting sessions queue behind it, each waiting on an <code>LCK_M_*</code> wait and each pinning a worker from SQL Server&rsquo;s fixed-size pool. As the chain deepens, the worker pool drains. Once exhausted, new requests get <code>THREADPOOL</code> waits and the instance appears down to applications, even though the OS shows <code>sqlservr</code> healthy and storage idle.</p>https://www.netdata.cloud/guides/microsoft-sql-server/microsoft-sql-server-cpu-utilization-high/Mon, 01 Jan 0001 00:00:00 +0000https://www.netdata.cloud/guides/microsoft-sql-server/microsoft-sql-server-cpu-utilization-high/<p>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).</p>https://www.netdata.cloud/guides/microsoft-sql-server/microsoft-sql-server-cxpacket-cxconsumer-waits/Mon, 01 Jan 0001 00:00:00 +0000https://www.netdata.cloud/guides/microsoft-sql-server/microsoft-sql-server-cxpacket-cxconsumer-waits/<p>You opened <code>sys.dm_os_wait_stats</code>, 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.</p> <p>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.</p>https://www.netdata.cloud/guides/microsoft-sql-server/microsoft-sql-server-database-suspect-recovery-pending/Mon, 01 Jan 0001 00:00:00 +0000https://www.netdata.cloud/guides/microsoft-sql-server/microsoft-sql-server-database-suspect-recovery-pending/<p>A production database is showing <code>state_desc = SUSPECT</code> or <code>RECOVERY_PENDING</code> in <code>sys.databases</code>. Applications cannot open connections to that database. Users are seeing login failures, query timeouts, or generic &ldquo;database cannot be opened&rdquo; errors. The SQL Server instance itself is up, and every other database on it may be fine.</p> <p><code>RECOVERY_PENDING</code> 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. <code>SUSPECT</code> 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 <code>DBCC CHECKDB</code> with <code>REPAIR_ALLOW_DATA_LOSS</code>. The right move is to fix the underlying resource, re-run recovery, and only fall back to repair or restore when that fails.</p>https://www.netdata.cloud/guides/microsoft-sql-server/microsoft-sql-server-error-1205-deadlock-victim/Mon, 01 Jan 0001 00:00:00 +0000https://www.netdata.cloud/guides/microsoft-sql-server/microsoft-sql-server-error-1205-deadlock-victim/<p>The error text returned to the client is explicit:</p> <blockquote> <p>Transaction (Process ID %d) was deadlocked on %.*ls resources with another process and has been chosen as the deadlock victim. Rerun the transaction.</p> </blockquote> <p><code>%d</code> is the SPID. <code>%.*ls</code> names the resource type, typically <code>lock</code>. 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.</p>https://www.netdata.cloud/guides/microsoft-sql-server/microsoft-sql-server-error-18456-login-failed/Mon, 01 Jan 0001 00:00:00 +0000https://www.netdata.cloud/guides/microsoft-sql-server/microsoft-sql-server-error-18456-login-failed/<p>SQL Server Error 18456 is the universal &ldquo;Login failed for user X&rdquo; message. It is deliberately vague: every client, from <code>sqlcmd</code> to the application&rsquo;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.</p>https://www.netdata.cloud/guides/microsoft-sql-server/microsoft-sql-server-error-701-insufficient-memory/Mon, 01 Jan 0001 00:00:00 +0000https://www.netdata.cloud/guides/microsoft-sql-server/microsoft-sql-server-error-701-insufficient-memory/<p>Error 701 is one of SQL Server&rsquo;s bluntest messages: &ldquo;There is insufficient system memory in resource pool &lsquo;default&rsquo; to run this query.&rdquo; 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).</p> <p>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.</p>https://www.netdata.cloud/guides/microsoft-sql-server/microsoft-sql-server-error-823-824-io-errors/Mon, 01 Jan 0001 00:00:00 +0000https://www.netdata.cloud/guides/microsoft-sql-server/microsoft-sql-server-error-823-824-io-errors/<p>Errors 823 and 824 are SQL Server&rsquo;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.</p> <p>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.</p>https://www.netdata.cloud/guides/microsoft-sql-server/microsoft-sql-server-error-825-read-retry/Mon, 01 Jan 0001 00:00:00 +0000https://www.netdata.cloud/guides/microsoft-sql-server/microsoft-sql-server-error-825-read-retry/<p>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.</p> <p>Most monitoring setups never surface Error 825. It is a severity-10 informational message, and typical SQL Server Agent alert configurations target severity 20 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.</p>https://www.netdata.cloud/guides/microsoft-sql-server/microsoft-sql-server-error-9002-transaction-log-full/Mon, 01 Jan 0001 00:00:00 +0000https://www.netdata.cloud/guides/microsoft-sql-server/microsoft-sql-server-error-9002-transaction-log-full/<p>Your application is throwing write failures and the SQL Server error log shows: &ldquo;The transaction log for database &lsquo;X&rsquo; is full due to &lsquo;LOG_BACKUP&rsquo;&rdquo; (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.</p> <p>This is the most common unexpected SQL Server outage, and it is preventable. It is also frequently mishandled: the instinctive responses, &ldquo;add more disk space&rdquo; and &ldquo;shrink the log,&rdquo; treat the symptom while the log keeps growing. The log is full because it cannot be truncated, and the reason it cannot be truncated is stated explicitly in <code>sys.databases.log_reuse_wait_desc</code>. Read that first, fix that, then deal with the space.</p>https://www.netdata.cloud/guides/microsoft-sql-server/microsoft-sql-server-instance-down/Mon, 01 Jan 0001 00:00:00 +0000https://www.netdata.cloud/guides/microsoft-sql-server/microsoft-sql-server-instance-down/<p>Your availability probe just fired: TCP connect plus <code>SELECT 1</code> 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 &ldquo;SQL Server is down&rdquo;. They have different causes, different fixes, and different blast radii.</p> <p>Mode one: no TCP connect at all. The listener is not accepting connections on 1433 (or the named instance&rsquo;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.</p>https://www.netdata.cloud/guides/microsoft-sql-server/microsoft-sql-server-pageiolatch-waits/Mon, 01 Jan 0001 00:00:00 +0000https://www.netdata.cloud/guides/microsoft-sql-server/microsoft-sql-server-pageiolatch-waits/<p>Your top wait type is <code>PAGEIOLATCH_SH</code> or <code>PAGEIOLATCH_EX</code>. 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.</p> <p>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.</p>https://www.netdata.cloud/guides/microsoft-sql-server/microsoft-sql-server-resource-semaphore-waits/Mon, 01 Jan 0001 00:00:00 +0000https://www.netdata.cloud/guides/microsoft-sql-server/microsoft-sql-server-resource-semaphore-waits/<p>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.</p> <p>CPU may be low. Disk I/O may be low. Buffer pool may look fine. Users report &ldquo;the database is slow&rdquo; and standard dashboards do not explain why. RESOURCE_SEMAPHORE only shows up clearly if you sample wait stats on a short interval and watch the Memory Grants Pending counter. Both are routinely missed.</p>https://www.netdata.cloud/guides/microsoft-sql-server/microsoft-sql-server-sos-scheduler-yield-waits/Mon, 01 Jan 0001 00:00:00 +0000https://www.netdata.cloud/guides/microsoft-sql-server/microsoft-sql-server-sos-scheduler-yield-waits/<p>When SOS_SCHEDULER_YIELD dominates <code>sys.dm_os_wait_stats</code>, 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.</p> <p>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.</p>https://www.netdata.cloud/guides/microsoft-sql-server/microsoft-sql-server-tempdb-full/Mon, 01 Jan 0001 00:00:00 +0000https://www.netdata.cloud/guides/microsoft-sql-server/microsoft-sql-server-tempdb-full/<p>Applications start failing with error 1105 (&ldquo;could not allocate space for object in database &rsquo;tempdb&rsquo; because the &lsquo;PRIMARY&rsquo; filegroup is full&rdquo;) 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.</p> <p>This is an instance-wide outage with a single shared point of failure, and it usually has one dominant consumer. The diagnostic job is short: identify which of the three consumer categories filled TempDB, find the sessions responsible, relieve the space pressure, then fix the root cause so it does not recur tomorrow.</p>https://www.netdata.cloud/guides/microsoft-sql-server/microsoft-sql-server-threadpool-waits/Mon, 01 Jan 0001 00:00:00 +0000https://www.netdata.cloud/guides/microsoft-sql-server/microsoft-sql-server-threadpool-waits/<p>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.</p> <p>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&rsquo;s perspective this is equivalent to connection refusal. The server is not slow. It is not accepting work at all.</p>