https://www.netdata.cloud/tags/sql-server/Recent content in SQL Server on NetdataHugoen-usMon, 31 Aug 2026 20:45:44 +0300https://www.netdata.cloud/blog/dbm/Fri, 24 Apr 2026 00:00:00 +0000https://www.netdata.cloud/blog/dbm/<p><img src="../images/dbm-hero.svg" alt="Database Performance Monitoring: Query-Level Visibility Across 14+ Databases"></p> <p>Netdata has always collected database metrics: connections, throughput, replication lag, buffer cache hit ratios, and so on. These tell you that something is wrong, but they don&rsquo;t tell you why. When your PostgreSQL response time spikes, the metric alone doesn&rsquo;t tell you which query is responsible. For that, you&rsquo;ve traditionally needed to SSH into the box, connect to the database, and run diagnostic queries manually. Or set up a separate database monitoring tool entirely.</p>https://www.netdata.cloud/solutions/built-for/dbas/Tue, 27 Jan 2026 00:00:00 +0000https://www.netdata.cloud/solutions/built-for/dbas/Netdata gives DBAs complete database visibility with per-second query performance, replication lag tracking, lock analysis, and connection pool monitoring across MySQL, PostgreSQL, SQL Server, Oracle, and MongoDB - all from one dashboard with zero configuration.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/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-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-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/webinars/live-functions-database-network-monitoring/Mon, 01 Jan 0001 00:00:00 +0000https://www.netdata.cloud/webinars/live-functions-database-network-monitoring/https://www.netdata.cloud/webinars/windows-server-monitoring/Mon, 01 Jan 0001 00:00:00 +0000https://www.netdata.cloud/webinars/windows-server-monitoring/