SQL Server exposes an enormous amount of performance information, but not every metric that moves outside a “normal” range indicates a performance problem. The most useful SQL Server performance metrics are the ones that help you understand how the server is using resources, how workloads are behaving, and whether performance is changing over time.

The key SQL Server performance metrics to monitor include CPU utilization, memory pressure, disk latency, I/O, wait statistics, query duration, blocking, deadlocks, batch requests, database growth, transaction log usage, and TempDB activity. These metrics become much more useful when viewed together and compared against a reliable baseline for the specific environment.

The goal of DBAs and IT leaders is to identify the measurements that can answer three important questions:

1. Is SQL Server performing as expected?
2. If not, what is causing the problem?
3. Did our changes actually improve performance?

Why SQL Server Performance Metrics Matter

SQL Server performance problems rarely have a single universal indicator. A server showing 90% CPU utilization isn’t automatically unhealthy; a database with high disk I/O isn’t necessarily experiencing a storage problem; and a high Page Life Expectancy value doesn’t automatically mean everything is fine.

Performance metrics need context. That context comes from looking at multiple measurements, understanding the workload, and comparing current behavior against an established baseline.

For example, if CPU utilization has historically remained around 40% and suddenly increases to 95% while query response times also increase and the number of runnable tasks rises, that’s much more meaningful than simply seeing a CPU percentage of 95%.

This is why experienced DBAs don’t generally ask, “Is this metric above the threshold?” They ask, “What changed, and what does the combination of metrics tell us?”

The Most Important SQL Server Performance Metrics

1. CPU Utilization

CPU utilization is one of the most commonly monitored SQL Server performance metrics. It tells you how heavily the available processor resources are being used. Sustained CPU pressure can contribute to slow queries, increased response times, and application performance problems.

But CPU percentage alone doesn’t tell you why the CPU is busy. High CPU utilization can result from:

• Inefficient queries
• Increased workload
• Poor execution plans
• Excessive parallelism
• Missing or ineffective indexes
• Configuration issues
• Other processes competing for CPU resources

When evaluating CPU, look at it alongside query CPU time, wait statistics, runnable tasks, and workload changes.

What to look for: Sustained CPU pressure, especially when it coincides with increased query response times or other indicators of resource contention.

2. Memory Utilization and Memory Pressure

SQL Server relies heavily on memory for caching data and execution plans. Memory pressure occurs when SQL Server doesn’t have enough memory available to efficiently support the workload.

Useful indicators include:

• SQL Server memory usage
• Available server memory
• Memory grants
• Page Life Expectancy
• Memory-related wait statistics
• Memory grants pending

Page Life Expectancy (PLE) is often discussed as a standalone threshold, but there is no single PLE number that determines whether a SQL Server is healthy or unhealthy. A sudden and sustained change in PLE relative to the server’s normal behavior can be more informative than a universal threshold.

What to look for: Evidence that SQL Server is experiencing memory pressure, particularly when it coincides with increased I/O, query performance degradation, or memory-related waits.

3. Disk Latency

Disk latency measures how long storage operations take. High latency can cause SQL Server queries to wait for data to be read from or written to storage.

Storage performance is particularly important for:

• Data files
• Transaction log files
• TempDB
• Backup operations

High disk latency can be caused by inadequate storage performance, storage contention, configuration problems, or workloads that generate unusually heavy I/O.

What to look for: Sustained latency that is materially higher than the environment’s established baseline, especially when SQL Server workloads are experiencing corresponding I/O waits.

4. I/O Throughput

I/O throughput measures the amount of data being read from or written to storage. Looking only at throughput can be misleading. A workload generating high I/O isn’t necessarily unhealthy if the storage system is handling it efficiently. Conversely, relatively modest I/O can still cause problems if storage latency is high. That’s why I/O throughput should generally be evaluated together with latency and wait statistics.

What to look for: Changes in I/O patterns, unexpectedly high I/O, or increasing latency under workloads that previously performed normally.

5. Wait Statistics

Wait statistics are among the most useful sources of information for diagnosing SQL Server performance problems. SQL Server records information about what resources sessions are waiting for. Those waits can provide clues about where time is being spent.

Common categories include waits associated with:

• CPU scheduling
• Storage I/O
• Locking and blocking
• Memory
• Parallelism
• Network activity

Wait statistics shouldn’t be interpreted as a simple list of “bad waits.” A wait type that is perfectly normal in one environment may indicate a problem in another. The most useful approach is to examine which waits are significant, how they have changed, and how they relate to the workload and other performance metrics.

What to look for: Significant changes from baseline, dominant waits that correspond to reported performance problems, and wait patterns that point toward a specific resource bottleneck.

6. Query Duration

Query duration measures how long queries take to execute. Tracking query duration can help identify:

• Slow queries
• Changes in application performance
• Queries that have regressed
• Workloads consuming increasing amounts of resources

However, duration should be evaluated in context. A query that normally takes 30 seconds may be performing exactly as designed. A query that normally takes 100 milliseconds but suddenly takes five seconds represents a much more meaningful change.

What to look for: Changes in execution duration compared with historical performance or established baselines.

7. Query CPU Time

Query CPU time measures how much CPU processing a query consumes. A query with high CPU consumption may indicate:

• Inefficient T-SQL
• Poor execution plans
• Missing indexes
• Large scans
• Excessive calculations
• Increased workload

High CPU doesn’t automatically mean a query is poorly written. A legitimate analytical query may naturally require substantial CPU, so the best question is whether the CPU consumption is appropriate for the workload.

8. Logical Reads and Writes

Logical reads indicate how many data pages SQL Server reads from the buffer pool to satisfy a query. A query performing an unexpectedly large number of logical reads may be scanning more data than necessary.

High logical reads can be associated with:

• Missing indexes
• Inefficient queries
• Poor execution plans
• Large table scans
• Inappropriate filtering

Logical reads can be especially useful when comparing different versions of a query or determining whether a tuning change actually reduced the amount of work SQL Server must perform.

9. Blocking

Blocking occurs when one session holds a lock that prevents another session from proceeding. While some blocking is normal in SQL Server, persistent or excessive blocking isn’t. If users or applications frequently experience delays because sessions are waiting on other sessions, you need to understand why.

Common contributors include:

• Long-running transactions
• Inefficient queries
• Poor indexing
• Application transaction design
• High concurrency
• Lock escalation

What to look for: Frequency, duration, affected sessions, and whether blocking coincides with user-facing performance problems.

10. Deadlocks

A deadlock occurs when two or more sessions are waiting on resources held by one another, creating a cycle in which none can proceed. SQL Server detects deadlocks and chooses one transaction as the deadlock victim so that the others can continue.

An occasional deadlock may not indicate a serious problem. Recurring deadlocks, however, deserve investigation, particularly when they affect important business processes. The goal is to understand the queries, transactions, indexes, and application behavior creating the condition.

11. Batch Requests/sec

Batch Requests/sec measures the number of batches SQL Server receives and processes per second. It can provide a useful indication of workload activity and can help establish how busy a SQL Server is over time. However, there is no universal “good” or “bad” value.

A high number of batch requests doesn’t necessarily mean SQL Server is unhealthy, and a low number doesn’t necessarily mean performance is good. The metric becomes more useful when you compare it with:

• CPU utilization
• Query duration
• Wait statistics
• Transactions
• Historical workload

What to look for: Significant changes from the normal workload pattern and changes that coincide with resource pressure or performance degradation.

12. SQL Compilations and Recompilations

SQL Server compiles execution plans so it can execute queries efficiently. A high rate of compilations or recompilations can consume CPU and may indicate that SQL Server is repeatedly generating execution plans instead of efficiently reusing them.

Potential contributors include:

• Ad hoc workloads
• Changing query structures
• Schema changes
• Statistics changes
• Certain query or application behaviors

These metrics are most useful when evaluated in the context of overall workload and CPU utilization.

13. Database Growth

Database size and growth rate aren’t traditional performance counters but do serve as important operational performance metrics. As databases grow, workloads may change. Growth can affect:

• Storage capacity
• Backup duration
• Maintenance operations
• Index maintenance
• Query performance
• Recovery operations

Monitoring database growth also provides an important capacity-planning signal. A database that’s growing rapidly today may create a storage or performance problem months from now even if the server is operating normally today.

14. Transaction Log Usage

Transaction log utilization is another important metric to monitor. A transaction log that repeatedly approaches capacity can indicate:

• Long-running transactions
• Failed or delayed log backups
• Replication or availability issues
• Unexpected workload behavior
• An incorrectly sized log file

A full transaction log can cause application failures, so this metric has both performance and availability implications.

15. TempDB Activity Activity

TempDB is used by SQL Server for many internal operations and user workloads. Heavy TempDB activity can be associated with:

• Sort operations
• Hash operations
• Temporary tables
• Table variables
• Row versioning
• Snapshot isolation
• Other internal SQL Server processes

TempDB contention or inadequate configuration can contribute to performance problems.

Monitor TempDB usage, file configuration, growth, and relevant wait statistics rather than focusing on one number in isolation.

Which SQL Server Metrics Actually Signal a Performance Problem?

This is where performance monitoring can become misleading. There is rarely a single metric that proves SQL Server has a performance problem. Instead, look for patterns and correlations.

For example:

The strongest signal is often several metrics changing at the same time.

For example, if query duration increases, CPU rises, logical reads increase, and execution plans show a regression, you have considerably more evidence of a performance problem than you would from CPU utilization alone.

What Is a SQL Server Performance Baseline?

A performance baseline is a record of what normal SQL Server performance looks like in a particular environment. This is one of the most valuable things you can establish when monitoring SQL Server. A baseline might include:

• Typical CPU utilization
• Memory utilization
• Disk latency
• I/O patterns
• Wait statistics
• Batch requests
• Query duration
• Database growth
• Transaction log usage
• Blocking
• Deadlocks

The baseline should represent normal workload conditions rather than a single moment in time.

For example, a reporting server may have very different performance characteristics during business hours than overnight. A baseline that ignores those patterns won’t be very useful.

Why Baselines Matter More Than Universal Thresholds

It’s tempting to search for a number that defines when a SQL Server metric becomes “bad.” Unfortunately, SQL Server performance doesn’t work that neatly. A CPU utilization level that is perfectly acceptable for one workload may be a problem for another. The same applies to memory utilization, I/O, batch requests, and many other metrics.

Your own historical baseline is often more useful than a generic threshold. A significant change from normal behavior can be a better signal than crossing an arbitrary number. This doesn’t mean thresholds aren’t useful. They can be valuable for monitoring and alerting.

But thresholds should be treated as signals for investigation, not automatic proof that something is wrong.

How Should I Standardize SQL Server Performance Baselines?

Organizations with multiple SQL Server environments face another challenge: comparing performance across servers. A standardized baseline can make that easier. At a minimum, establish a consistent set of metrics across environments, such as:

• CPU
• Memory
• Disk latency
• I/O
• Wait statistics
• Batch Requests/sec
• Query duration
• Blocking
• Deadlocks
• Database growth
• Transaction log utilization

Then document the conditions under which the measurements were taken. For example:

• Server hardware
• SQL Server version
• Workload
• Time of day
• Business cycle
• Database size
• Number of users
• Major applications running

This prevents misleading comparisons. A development server, an OLTP production server, and a reporting server shouldn’t necessarily have identical performance characteristics. Standardize the measurements, not necessarily the expected values.

When Should I Tune SQL Server Performance?

Performance tuning should generally begin when metrics indicate a meaningful performance problem that affects users, applications, business processes, or resource utilization. Some situations that warrant investigation include:

• Persistent performance degradation
• Increasing query duration
• Recurring blocking
• Frequent deadlocks
• Sustained resource pressure
• Significant changes from baseline
• Application timeouts
• Failed or delayed workloads
• Increasing I/O latency
• Queries consuming disproportionate resources

Not every metric outside its normal range requires immediate tuning. The better question is: Is the condition materially affecting the workload, and can we identify a specific opportunity to improve it?

How Do I Measure the ROI of SQL Server Performance Tuning?

Performance tuning shouldn’t be evaluated solely by whether a query became faster. The business impact matters. Depending on the environment, useful measures may include:

• Reduced query duration
• Reduced CPU consumption
• Reduced I/O
• Fewer timeouts
• Fewer blocking incidents
• Reduced application response time
• Increased transaction throughput
• Reduced infrastructure requirements
• Fewer performance-related incidents
• Improved user productivity

For example, reducing a query from 10 seconds to 2 seconds sounds impressive. But if that query runs twice a day, the business impact may be limited. In contrast, if a query that runs 100,000 times per day is reduced from 500 milliseconds to 100 milliseconds, the improvement may be substantially more meaningful.

Measure performance improvements against workload frequency and business impact, not just percentage improvement.

How Do I Know if Performance Tuning Actually Worked?

Establish a baseline before making the change. Then compare the same metrics afterward. Depending on the tuning effort, that might include:

• Query duration before and after
• CPU consumption
• Logical reads
• Physical reads
• I/O latency
• Wait statistics
• Blocking
• Application response time
• Throughput

The comparison should ideally use comparable workloads. If possible, measure over enough time to account for normal workload variation. A change that improves performance for one query during a five-minute test isn’t necessarily an improvement for the production environment.

How Do I Measure SQL Server Performance?

SQL Server provides several sources of performance information.

SQL Server Management Studio

SSMS provides access to execution plans, query statistics, Activity Monitor, Extended Events, and other diagnostic capabilities.

Dynamic Management Views

SQL Server’s Dynamic Management Views (DMVs) provide information about queries, waits, indexes, memory, sessions, and other aspects of SQL Server activity.

Query Store

Query Store retains information about query execution and performance over time, making it particularly useful for identifying query regressions.

Windows Performance Monitor

Windows Performance Monitor can provide operating-system-level information that helps correlate SQL Server activity with CPU, memory, disk, and other resources.

SQL Server Monitoring Tools

Third-party monitoring platforms can collect metrics continuously, maintain historical information, and alert administrators when defined conditions occur. The important point is having reliable performance information over time and knowing how to interpret it.

SQL Server Performance Metrics vs. a SQL Server Health Check

Performance metrics are an important part of a SQL Server Health Check, but they aren’t the whole picture. A Health Check can also evaluate:

• • Configuration
  • Security

• Backup and recovery
• Database integrity
• Storage capacity
• High availability and disaster recovery
• SQL Server Agent
• Dependencies
• Future capacity

Monitoring performance metrics tells you how SQL Server is behaving; A Health Check takes a broader look at whether the environment is healthy and properly configured. The two approaches work best together. 

Frequently Asked Questions

What are the most important SQL Server performance metrics?

Some of the most useful metrics include CPU utilization, memory pressure, disk latency, I/O, wait statistics, query duration, logical reads, blocking, deadlocks, database growth, transaction log utilization, and TempDB activity. The most important metrics for a particular environment depends on its workload and architecture.

What is a good CPU percentage for SQL Server?

There is no universal CPU percentage that defines a healthy SQL Server. Sustained high CPU utilization can indicate resource pressure, but CPU should be evaluated alongside query performance, wait statistics, runnable tasks, workload changes, and other metrics.

What is a good Page Life Expectancy for SQL Server?

There is no universal PLE value that determines whether SQL Server has sufficient memory. PLE should be evaluated in the context of the server’s workload, memory configuration, and historical behavior. Changes from the environment’s normal baseline can be more useful than an arbitrary threshold.

What SQL Server metrics indicate a performance problem?

Performance problems are generally indicated by patterns rather than a single metric. Examples include sustained resource pressure, increasing query duration, excessive waits, increasing I/O latency, recurring blocking, deadlocks, and significant changes from an established performance baseline.

What are SQL Server wait statistics?

Wait statistics provide information about the resources SQL Server sessions are waiting for. They can help identify potential bottlenecks involving CPU scheduling, storage, locking, memory, parallelism, and other resources.

How often should SQL Server performance metrics be monitored?

Production SQL Server environments generally benefit from continuous monitoring. The appropriate level of monitoring depends on the workload’s criticality, but important systems should have enough historical data to establish baselines and identify trends and intermittent problems.

What is a SQL Server performance baseline?

A performance baseline is a record of normal SQL Server behavior under representative workloads. It provides a reference point for identifying changes and evaluating whether performance improvements actually worked.

Can SQL Server performance metrics predict problems?

They can help identify trends and conditions that increase the likelihood of future problems, but metrics cannot predict every SQL Server failure. Monitoring trends such as database growth, increasing resource utilization, and declining performance can provide valuable early warning.

Should every SQL Server performance metric have an alert threshold?

No. Alerting on every available metric can create excessive noise and make important alerts harder to recognize. Focus your alerts on meaningful conditions and use historical metrics and baselines for deeper analysis.

How do I know whether SQL Server performance tuning was successful?

Compare performance against a baseline established before tuning. Useful measures include query duration, CPU, logical reads, I/O, waits, blocking, throughput, and application response time. The most meaningful measure is whether the change improved the workload and produced a measurable business benefit.

Need Help Understanding Your SQL Server Performance Metrics?

SQL Server provides an enormous amount of performance information, but collecting metrics is only the first step. The real value comes from understanding what the numbers mean, establishing a reliable baseline, identifying meaningful changes, and determining which problems actually deserve attention.

SSG helps organizations identify and resolve SQL Server performance and operational problems. Whether you need help interpreting performance metrics, establishing baselines, investigating a persistent bottleneck, or determining whether your environment needs a broader Health Check, our SQL Server experts can help.

The post The Complete Guide to SQL Server Performance Metrics appeared first on SQL Solutions Group.

We recently had a scenario where we were rebuilding a large index for a customer over a long weekend. We were monitoring closely, as this has caused production issues in the past. After 2.5 hours, we did not see any progress on the rebuild.

For full visibility, this rebuild was being performed by the Ola Hallengren index optimize stored procedure and was using this command (anonymized):

ALTER INDEX [IndexName] ON [dbo].[TableName] REBUILD WITH (SORT_IN_TEMPDB = OFF, ONLINE = ON, MAXDOP = 8, FILLFACTOR = 100, RESUMABLE = OFF)

This is what we see in sp_whoisactive, we were not blocked, we were not waiting on any resources but our % completion is at 0 still.

Are We Making Progress?

We can go directly to the source if we choose and query sys.dm_exec_requests to check our progress from there.

SELECT

r.session_id,

r.status,

r.command,

r.blocking_session_id,

r.wait_type,

r.wait_time / 1000.0 AS wait_seconds,

r.wait_resource,

r.total_elapsed_time / 1000.0 AS elapsed_seconds,

r.percent_complete

FROM sys.dm_exec_requests AS r

WHERE r.session_id = /*your spid*/;

However we see 0% here too:

The reason is actually interesting. The official documentation does state that the percent_complete column does not include index rebuilds, but rather only index reorgs (and other not directly related commands).

So that explains our predicament here: This DMV just doesn’t provide data for rebuilds like ours. Because of this we’re going to have to look at different options.

Pursuing Options

Luckily, we’re on a new enough version of SQL Server that we have lightweight query profiling enabled:

SELECT name, value, value_for_secondary

FROM sys.database_scoped_configurations

WHERE name = 'LIGHTWEIGHT_QUERY_PROFILING';

Because of this, we can use sys.dm_exec_query_profiles to see how far along the query believes itself to be.

SELECT

qp.node_id,

qp.physical_operator_name,

qp.row_count,

qp.estimate_row_count,

CAST(qp.row_count AS DECIMAL(18,2))

/ NULLIF(qp.estimate_row_count, 0) * 100 AS pct_complete_by_rows,

qp.elapsed_time_ms / 1000.0 AS elapsed_seconds,

qp.cpu_time_ms / 1000.0 AS cpu_seconds

FROM sys.dm_exec_query_profiles AS qp

WHERE qp.session_id = /*your spid here */

ORDER BY qp.node_id;

From the results, we can see that we’re still actually reading our data from the source table:

As we’re running with a MAXDOP of 8, we can see the separate threads here and their individual progress.

It’s worth making clear that these are estimated row counts, not actuals.  They are only as good as your statistics on these tables are. However, when I ran this again a few minutes later, we can see that our parallel threads are still making progress and not stuck at 0% as we were, at first, lead to believe:

Notice that a couple of threads are over 100% completion. That’s due to statistics that aren’t quite right and the actual row counts are above that.

We can make this query a little more concise if we choose:

SELECT

qp.node_id,

qp.physical_operator_name,

SUM(qp.row_count) AS total_rows_processed,

SUM(qp.estimate_row_count) AS total_estimated_rows,

CAST(SUM(qp.row_count) AS DECIMAL(18,2))

/ NULLIF(SUM(qp.estimate_row_count), 0) * 100 AS pct_complete,

SUM(qp.elapsed_time_ms) / 1000.0 AS elapsed_seconds,

SUM(qp.cpu_time_ms) / 1000.0 AS cpu_seconds

FROM sys.dm_exec_query_profiles AS qp

WHERE qp.session_id = 468

GROUP BY qp.node_id, qp.physical_operator_name

ORDER BY qp.node_id;

</ br>

Lies, Damn Lies, and Statistics

That tells us that we’re 94% complete with our index scan at this point and we can continue to monitor from here. What’s interesting for this scenario — and I need to test this further — is that the scans took all of the time for this query. Once those had finished, it completed almost instantly. 0%, my foot!

I hope this helps those of you sitting there looking at a blank completion figure and having a low-level anxiety attack.

</ br>

---

 

If SQL Server is doing something you can’t decipher, we’d love to help! Put our 90+ years of combined SQL Server experience to work for you.

The post When your index rebuilds are stuck at 0% (but lying to you) appeared first on SQL Solutions Group.

The specific issue is that the tempdb log file for a specific customer was filling up, growing, and then filling the drive. There was no obvious cause. We did the usual, checking which processes were using tempdb space with sys.dm_db_session_space_usage, but there weren’t any using anywhere near the amount of pages that would explain the file filling. But it kept growing.

Something else: When checking sp_WhoIsActive, we saw hundreds of sleeping transactions which weren’t actually using any resources. They were just sitting there open, which is not normal behaviour for queries/connections to SQL Server.

Version Store

I’m going to give away the ending here. This issue was indeed caused by an open sleeping transaction, but it was not directly related to the actual process running. This environment has Read Committed Snapshot Isolation (RCSI) enabled. The open query was causing any data changes to be logged to the version store. This is normal. However, this — combined with the extremely long duration of the offending query — is what caused the version store to grow out of control.

By querying sys.dm_tran_active_snapshot_database_transactions, we can see a list of active transactions that are logging data to the version store. By using the transaction_id, we can query sys.dm_tran_active_transactions to find further details of our problem query here.

The simplest thing to do next is to then compare this with the output of sp_WhoIsActive and check the start_time of the query to find what our likely suspect is:

We can see that this query started at 11:04:19, which is 400ms off the time reported in the first query. But that’s close enough to help us find it.

The tricky part here is that none of the usual DMVs around file usage would uncover this. It’s a very niche DMV to check, so it’s very easily overlooked.

Once we killed this connection, we saw the templog file become empty, which allowed us to shrink it back to its original size. Voila!

Possible Solutions

We’ve got a couple of options here: the ‘correct’ way and a stopgap that you can use to beat active connections into submission. Pick your poison.

Option 1: Close connections correctly

The entire issue here is ultimately down to the fact that connections are not being closed when they’re no longer needed. There are various ways you can close these connections, depending on what language you’re writing your queries in. Whatever language you’re using, we should be closing those connections.

Don’t even get me started on worker thread exhaustion here too. That’s a whole different blog post.

Option 2: A Reactive Agent Job

The other approach is reactive: a scheduled Agent job that finds sessions which have been open too long, doing too little, and ends them.

We check a few things here:

• Is the templog file more than 75% full? If it’s not, then we take no action.
• Do we have any running transactions using version store that have been going for more than 120 seconds? This number is arbitrary and is very specific to your environment. Feel free to set this threshold to whatever feels appropriate for you.
• Find the session_id that relates to this transaction_id.
• Verify this session_id is not a system process and it’s also not us.
• Once we have that, we issue a kill command using dynamic SQL on this offending SPID.

All the while, we are logging information so that we can interrogate it afterwards. We definitely don’t want this type of query acting silently!

The Script

SET NOCOUNT ON;
-------------------------------------------------------------------
-- CONFIG
-------------------------------------------------------------------
DECLARE @ThresholdSeconds     INT   = 120;
DECLARE @TempdbLogPctTrigger  FLOAT = 75.0;   -- only act if tempdb log is >= this % full
-------------------------------------------------------------------
-- OPTIONAL: Persistent log table (created once if it doesn't exist)
-------------------------------------------------------------------
IF OBJECT_ID('dbo.LongTransactionKillLog', 'U') IS NULL
BEGIN
    CREATE TABLE dbo.LongTransactionKillLog
    (
        LogId            INT IDENTITY(1,1) PRIMARY KEY,
        LogTimeUtc       DATETIME2 DEFAULT SYSUTCDATETIME(),
        TransactionId    BIGINT NULL,
        SessionId        INT NULL,
        ElapsedSeconds   INT NULL,
        TempdbLogPctUsed FLOAT NULL,
        LoginName        SYSNAME NULL,
        HostName         SYSNAME NULL,
        ProgramName      NVARCHAR(256) NULL,
        LastQueryText    NVARCHAR(MAX) NULL,
        Action           VARCHAR(50),
        Message          NVARCHAR(4000)
    );
END;
-------------------------------------------------------------------
-- 0. Check tempdb log space usage — gate everything on this
-------------------------------------------------------------------
DECLARE @TempdbLogPctUsed FLOAT;
DECLARE @LogSpace TABLE
(
    DatabaseName          SYSNAME,
    LogSizeMB             FLOAT,
    LogSpaceUsedPct       FLOAT,
    Status                INT
);
INSERT INTO @LogSpace
EXEC ('DBCC SQLPERF(LOGSPACE)');
SELECT @TempdbLogPctUsed = LogSpaceUsedPct
FROM @LogSpace
WHERE DatabaseName = 'tempdb';
IF @TempdbLogPctUsed IS NULL
BEGIN
    INSERT INTO dbo.LongTransactionKillLog (TempdbLogPctUsed, Action, Message)
    VALUES (NULL, 'ABORTED', 'Could not determine tempdb log space usage via DBCC SQLPERF(LOGSPACE).');
    PRINT 'Could not determine tempdb log space usage. Aborting.';
    RETURN;
END;
PRINT 'Tempdb log space used: ' + CAST(@TempdbLogPctUsed AS VARCHAR(10)) + '%';
IF @TempdbLogPctUsed < @TempdbLogPctTrigger BEGIN INSERT INTO dbo.LongTransactionKillLog (TempdbLogPctUsed, Action, Message) VALUES (@TempdbLogPctUsed, 'NO_ACTION', 'Tempdb log usage (' + CAST(@TempdbLogPctUsed AS VARCHAR(10)) + '%) below trigger threshold of ' + CAST(@TempdbLogPctTrigger AS VARCHAR(10)) + '%. No action taken.'); PRINT 'Tempdb log usage below ' + CAST(@TempdbLogPctTrigger AS VARCHAR(10)) + '% threshold. No action taken.'; RETURN; END; PRINT 'Tempdb log usage exceeds ' + CAST(@TempdbLogPctTrigger AS VARCHAR(10)) + '% threshold — proceeding with transaction check.'; ------------------------------------------------------------------- -- 1. Find the longest-running transaction over the threshold ------------------------------------------------------------------- DECLARE @TransactionId BIGINT; DECLARE @ElapsedSeconds INT; SELECT TOP 1 @TransactionId = transaction_id, @ElapsedSeconds = elapsed_time_seconds FROM sys.dm_tran_active_snapshot_database_transactions WHERE elapsed_time_seconds >= @ThresholdSeconds
ORDER BY elapsed_time_seconds DESC;
IF @TransactionId IS NULL
BEGIN
    INSERT INTO dbo.LongTransactionKillLog (TransactionId, SessionId, ElapsedSeconds, TempdbLogPctUsed, Action, Message)
    VALUES (NULL, NULL, NULL, @TempdbLogPctUsed, 'NO_ACTION',
            'Tempdb log over threshold, but no transaction found exceeding ' + CAST(@ThresholdSeconds AS VARCHAR(10)) + ' second duration threshold.');
    PRINT 'No transaction found exceeding ' + CAST(@ThresholdSeconds AS VARCHAR(10)) + ' second threshold.';
    RETURN;
END;
PRINT 'Longest transaction found: transaction_id = ' + CAST(@TransactionId AS VARCHAR(20))
    + ', elapsed_time_seconds = ' + CAST(@ElapsedSeconds AS VARCHAR(10));
-------------------------------------------------------------------
-- 2. Resolve transaction_id -> session_id
-------------------------------------------------------------------
DECLARE @SessionId INT;
SELECT TOP 1
    @SessionId = st.session_id
FROM sys.dm_tran_session_transactions st
WHERE st.transaction_id = @TransactionId;
IF @SessionId IS NULL
BEGIN
    INSERT INTO dbo.LongTransactionKillLog (TransactionId, SessionId, ElapsedSeconds, TempdbLogPctUsed, Action, Message)
    VALUES (@TransactionId, NULL, @ElapsedSeconds, @TempdbLogPctUsed, 'NO_ACTION', 'Could not resolve session_id for transaction_id.');
    PRINT 'Could not resolve a session_id for transaction_id ' + CAST(@TransactionId AS VARCHAR(20)) + '.';
    RETURN;
END;
-------------------------------------------------------------------
-- 3. Pull session context for logging (before kill, while it's alive)
-------------------------------------------------------------------
DECLARE @LoginName   SYSNAME;
DECLARE @HostName    SYSNAME;
DECLARE @ProgramName NVARCHAR(256);
DECLARE @LastQuery   NVARCHAR(MAX);
SELECT
    @LoginName   = s.login_name,
    @HostName    = s.host_name,
    @ProgramName = s.program_name
FROM sys.dm_exec_sessions s
WHERE s.session_id = @SessionId;
SELECT TOP 1
    @LastQuery = t.text
FROM sys.dm_exec_requests r
CROSS APPLY sys.dm_exec_sql_text(r.sql_handle) t
WHERE r.session_id = @SessionId;
IF @LastQuery IS NULL
BEGIN
    SELECT TOP 1
        @LastQuery = t.text
    FROM sys.dm_exec_connections c
    CROSS APPLY sys.dm_exec_sql_text(c.most_recent_sql_handle) t
    WHERE c.session_id = @SessionId;
END;
-------------------------------------------------------------------
-- 4. Safety checks — don't kill system sessions or yourself
-------------------------------------------------------------------
IF @SessionId <= 50
BEGIN
    INSERT INTO dbo.LongTransactionKillLog
        (TransactionId, SessionId, ElapsedSeconds, TempdbLogPctUsed, LoginName, HostName, ProgramName, LastQueryText, Action, Message)
    VALUES
        (@TransactionId, @SessionId, @ElapsedSeconds, @TempdbLogPctUsed, @LoginName, @HostName, @ProgramName, @LastQuery,
         'ABORTED', 'Refused to kill: session_id <= 50 is a system session.');
    PRINT 'Refusing to kill session_id ' + CAST(@SessionId AS VARCHAR(10)) + ' — this is a system session.';
    RETURN;
END;
IF @SessionId = @@SPID
BEGIN
    INSERT INTO dbo.LongTransactionKillLog
        (TransactionId, SessionId, ElapsedSeconds, TempdbLogPctUsed, LoginName, HostName, ProgramName, LastQueryText, Action, Message)
    VALUES
        (@TransactionId, @SessionId, @ElapsedSeconds, @TempdbLogPctUsed, @LoginName, @HostName, @ProgramName, @LastQuery,
         'ABORTED', 'Refused to kill: target session is the current session.');
    PRINT 'Refusing to kill session_id ' + CAST(@SessionId AS VARCHAR(10)) + ' — that is this session.';
    RETURN;
END;
-------------------------------------------------------------------
-- 5. Log intent, then KILL
-------------------------------------------------------------------
INSERT INTO dbo.LongTransactionKillLog
    (TransactionId, SessionId, ElapsedSeconds, TempdbLogPctUsed, LoginName, HostName, ProgramName, LastQueryText, Action, Message)
VALUES
    (@TransactionId, @SessionId, @ElapsedSeconds, @TempdbLogPctUsed, @LoginName, @HostName, @ProgramName, @LastQuery,
     'KILL_ATTEMPT', 'About to issue KILL command.');
PRINT 'Killing session_id ' + CAST(@SessionId AS VARCHAR(10))
    + ' (transaction_id ' + CAST(@TransactionId AS VARCHAR(20)) + ', '
    + CAST(@ElapsedSeconds AS VARCHAR(10)) + 's elapsed, tempdb log ' + CAST(@TempdbLogPctUsed AS VARCHAR(10))
    + '% full, login: ' + ISNULL(@LoginName, 'N/A') + ')';
BEGIN TRY
    DECLARE @Sql NVARCHAR(100) = N'KILL ' + CAST(@SessionId AS NVARCHAR(10));
    EXEC (@Sql);
    UPDATE dbo.LongTransactionKillLog
    SET Action = 'KILL_ISSUED', Message = 'KILL command executed successfully.'
    WHERE LogId = SCOPE_IDENTITY();
    PRINT 'KILL command issued for session_id ' + CAST(@SessionId AS VARCHAR(10)) + '.';
END TRY
BEGIN CATCH
    DECLARE @ErrMsg NVARCHAR(4000) = ERROR_MESSAGE();
    INSERT INTO dbo.LongTransactionKillLog
        (TransactionId, SessionId, ElapsedSeconds, TempdbLogPctUsed, LoginName, HostName, ProgramName, LastQueryText, Action, Message)
    VALUES
        (@TransactionId, @SessionId, @ElapsedSeconds, @TempdbLogPctUsed, @LoginName, @HostName, @ProgramName, @LastQuery,
         'KILL_FAILED', @ErrMsg);
    PRINT 'Failed to kill session_id ' + CAST(@SessionId AS VARCHAR(10)) + ': ' + @ErrMsg;
END CATCH;

Bloated templog, Solved

So there you have it! If you want to run this regularly,  schedule the whole thing as a SQL Agent job step. For the first couple of weeks running this, I recommend you leave @DryRun = 1 before flipping it to actually kill anything. That log table alone is worth its weight in gold before you ever terminate a single session. It’ll tell you exactly who’s doing this and how often, which is far more persuasive in a conversation with a user than “I have a hunch.”

I hope this post solves an infuriating issue of bloated templog for somebody out there!

Still struggling and doubt the health of your instances? Our Health Check service may be just what you need.

The post The Mysterious Case of the Bloated templog appeared first on SQL Solutions Group.

The most effective way to improve query performance is to identify the root cause rather than relying on guesswork or broad system changes.

What Causes Slow SQL Server Queries?

Several factors commonly contribute to slow query performance.

Common causes include:

• Missing or inefficient indexes
• Poorly written queries
• Outdated statistics
• Blocking or deadlocks
• Large data volumes
• Memory or CPU pressure
• TempDB bottlenecks
• Execution plan changes

In many cases, multiple factors contribute to a query running slower than expected.

How Do You Identify a Slow Query?

SQL Server provides several tools for identifying and analyzing slow-running queries.

Common diagnostic tools include:

• Query Store
• Execution plans
• Wait statistics
• Dynamic Management Views (DMVs)
• SQL Server Extended Events
• Performance monitoring tools

Together, these tools help identify which queries consume the most resources and why.

Can Slow Queries Be Optimized?

Yes. Many slow queries can be improved without changing hardware.

Common optimization techniques include:

• Rewriting inefficient queries
• Creating or modifying indexes
• Updating statistics
• Reducing unnecessary data retrieval
• Optimizing joins and filtering
• Addressing blocking and resource contention

Even small improvements to frequently executed queries can have a significant impact on overall SQL Server performance.

Why Do Queries Suddenly Become Slow?

A query that performed well yesterday may slow down because of changes in data volume, execution plans, indexes, statistics, application updates, or overall workload. Investigating what changed is often the fastest path to identifying the underlying cause.

Historical tools such as Query Store can help determine when performance changed and whether execution plans were affected.

Can Hardware Fix Slow Queries?

Sometimes, but not always. Adding CPU, memory, or faster storage may improve performance if hardware resources are the primary bottleneck. However, inefficient queries, poor indexing, and execution plan issues often remain even after hardware upgrades. Optimizing the query itself is frequently the most cost-effective solution.

Frequently Asked Questions

How long should a SQL Server query take?

There is no universal benchmark. An acceptable execution time depends on the query, the amount of data being processed, and business requirements. A query that runs in a few seconds may be acceptable in one environment but unacceptable in another.

Why is a query fast one day and slow the next?

Performance can change because of data growth, updated statistics, execution plan changes, increased server workload, blocking, or application changes. Comparing current performance with historical data often helps identify what changed.

Can adding an index fix a slow query?

Sometimes. If the query is missing an appropriate index, adding one can dramatically improve performance. However, unnecessary or poorly designed indexes can increase maintenance overhead and may not solve the underlying problem.

Why is my query slow even though CPU usage is low?

Low CPU utilization doesn’t necessarily indicate good performance. A query may be waiting on disk I/O, locks, memory, TempDB, or other resources. Wait statistics can help identify where SQL Server is spending time waiting.

Should I rewrite a slow query or upgrade my hardware?

It depends on the root cause. Many performance issues can be resolved by optimizing queries, improving indexes, or updating statistics. Hardware upgrades may help when resource limitations are the primary bottleneck, but they rarely address inefficient query design.

What tools should I use to troubleshoot slow queries?

Query Store, execution plans, wait statistics, Dynamic Management Views (DMVs), and Extended Events are among the most valuable tools for diagnosing slow SQL Server queries. Using these tools together provides a more complete understanding of why a query is underperforming.

Related Articles

• What Is Query Store?
• What Are SQL Server Execution Plans?
• How Do I Troubleshoot SQL Server Performance Issues?
• What Are SQL Server Wait Statistics?

Need Help Improving Query Performance?

SQL Solutions Group helps organizations identify and resolve slow SQL Server queries using proven diagnostic techniques and performance tuning best practices. Whether the problem involves inefficient queries, indexing, execution plans, or resource bottlenecks, our consultants can help restore fast, reliable database performance.

The post Why Do I Have Slow Queries in SQL Server? appeared first on SQL Solutions Group.

However, not all fragmentation requires corrective action. The impact depends on factors such as index size, workload, storage type, and how the database is used.

What Causes Index Fragmentation?

Fragmentation naturally develops as data changes over time.

Common causes include:

• Frequent inserts
• Updates to indexed columns
• Deletes
• Page splits
• Changing data patterns
• High-transaction workloads

As databases grow, some degree of index fragmentation is normal.

How Can Index Fragmentation Affect Performance?

Excessive fragmentation can reduce query efficiency by increasing the number of pages SQL Server must read.

Potential effects include:

• Slower query performance
• Increased disk I/O
• Longer index maintenance operations
• Reduced efficiency during range scans

The impact varies depending on the workload. Some environments experience little or no noticeable effect, while others benefit significantly from index maintenance.

How Do You Measure Index Fragmentation?

SQL Server provides tools for measuring fragmentation levels across indexes.

Common methods include:

• Dynamic Management Views (DMVs)
• SQL Server Management Studio (SSMS)
• Maintenance and monitoring tools
• SQL Server Health Checks

Measuring fragmentation before taking action helps ensure maintenance efforts are focused where they provide the greatest benefit.

Should You Rebuild or Reorganize Indexes?

The appropriate maintenance strategy depends on the amount of fragmentation, index size, and workload. In some cases, reorganizing an index is sufficient. In others, rebuilding an index may provide greater benefit. Many organizations automate index maintenance as part of their regular database maintenance plan.

Rather than rebuilding every fragmented index, administrators should use measurable data to determine when maintenance is warranted.

Is Index Fragmentation Always a Problem?

No. Modern storage systems and SSDs have reduced the impact of fragmentation in many environments. Other factors—such as inefficient queries, missing indexes, blocking, or outdated statistics—often have a much greater effect on SQL Server performance. Index fragmentation should be evaluated as one part of an overall performance strategy rather than as an isolated issue.

Frequently Asked Questions

What is the difference between rebuilding and reorganizing an index?

Rebuilding an index creates a new copy of the index and removes fragmentation, while reorganizing an index defragments the existing structure without completely rebuilding it. The best choice depends on the amount of fragmentation, index size, and maintenance objectives.

How often should I rebuild SQL Server indexes?

There is no universal schedule. Some databases benefit from regular index maintenance, while others require it only occasionally. Maintenance decisions should be based on fragmentation levels, workload, and observed performance rather than a fixed calendar.

Does index fragmentation affect SSDs?

Yes, but often less than on traditional spinning disks. While fragmentation can still increase the number of pages SQL Server reads, overall query performance is frequently influenced more by indexing strategy, query design, and statistics than by physical fragmentation alone.

Can rebuilding indexes improve slow queries?

Sometimes. If fragmentation is contributing to poor performance, rebuilding or reorganizing an index may help. However, slow queries are more commonly caused by inefficient query design, missing indexes, outdated statistics, or resource bottlenecks.

Does rebuilding an index update statistics?

Yes. Rebuilding an index automatically updates its associated statistics with a full scan. Reorganizing an index does not, so statistics may still need to be updated separately depending on your maintenance strategy.

Should every fragmented index be rebuilt?

No. Rebuilding every fragmented index can consume significant CPU, memory, storage, and maintenance time without delivering meaningful performance improvements. It’s generally better to evaluate fragmentation alongside workload characteristics and overall system performance before deciding on maintenance.

Related Articles

• Why Do I Have Slow Queries in SQL Server?
• How Do I Troubleshoot SQL Server Performance Issues?
• What Is a SQL Server Health Check?

Need Help Optimizing SQL Server Performance?

SQL Solutions Group helps organizations evaluate index fragmentation as part of a comprehensive SQL Server performance assessment. Our consultants identify the issues that have the greatest impact on database performance and recommend practical solutions based on your workload and business requirements.

The post What is Index Fragmentation in SQL Server? appeared first on SQL Solutions Group.

Execution plans are one of the most valuable tools for troubleshooting slow queries because they reveal how SQL Server is actually executing the query—not just how it was written.

What Information Does an Execution Plan Show?

Execution plans contain detailed information about how SQL Server processes a query.

Common information includes:

• Index seeks and index scans
• Table scans
• Join operations
• Sort operations
• Estimated and actual row counts
• Operator costs
• Warnings about potential performance issues

Reviewing this information helps identify inefficient query execution and potential optimization opportunities.

Why Are Execution Plans Important?

Execution plans help explain why a query performs the way it does.

They can help identify:

• Missing or inefficient indexes
• Costly table scans
• Poor join strategies
• Outdated statistics
• Cardinality estimation issues
• Queries consuming excessive resources

Rather than guessing why a query is slow, administrators can use execution plans to understand how SQL Server arrived at its execution strategy.

What’s the Difference Between Estimated and Actual Execution Plans?

An estimated execution plan shows how SQL Server expects to execute a query before it runs, while an actual execution plan includes what happened during execution, including runtime statistics and actual row counts. Comparing the two can reveal differences between estimated and actual performance that may indicate optimization opportunities.

Can Execution Plans Identify Every Performance Problem?

No. Execution plans provide valuable insight into how individual queries are executed, but they represent only one part of SQL Server performance analysis. They are most effective when used alongside Query Store, wait statistics, performance counters, and other diagnostic tools to develop a complete understanding of database performance.

When Should You Review Execution Plans?

Execution plans should be reviewed whenever a query performs poorly, application performance declines, or database changes introduce unexpected behavior. They are also valuable after index changes, application updates, or SQL Server upgrades to verify that queries are using efficient execution strategies.

Frequently Asked Questions

What is the purpose of a SQL Server execution plan?

An execution plan shows how SQL Server processes a query to retrieve or modify data. It illustrates the operations SQL Server performs, such as index seeks, table scans, joins, and sorting, allowing database professionals to identify opportunities for query optimization.

How do I view an execution plan in SQL Server?

Execution plans can be viewed in SQL Server Management Studio (SSMS) by displaying the estimated or actual execution plan when running a query. Query Store can also provide access to execution plans for previously executed queries.

What’s the difference between an estimated and an actual execution plan?

An estimated execution plan shows how SQL Server expects a query to execute before it runs. An actual execution plan includes runtime information collected during execution, providing a more accurate picture of what actually happened and where performance issues may exist.

Can execution plans identify slow queries?

Execution plans help explain why a query is running slowly, but they don’t identify slow queries on their own. Tools such as Query Store and wait statistics are commonly used to find problematic queries before their execution plans are analyzed.

What are the most common performance problems revealed by execution plans?

Execution plans often reveal inefficient table scans, missing or unused indexes, expensive join operations, poor cardinality estimates, excessive sorting, and other operations that may contribute to slow query performance.

When should I analyze an execution plan?

Execution plans are most useful when investigating slow-running queries, recurring performance issues, or unexpected changes in query performance. They are commonly used alongside Query Store and wait statistics as part of a comprehensive SQL Server performance investigation.

Related Articles

• What Is Query Store?
• What Are SQL Server Wait Statistics?
• How Do I Troubleshoot SQL Server Performance Issues?
• Why Do I Have Slow Queries in SQL Server?

Need Help Analyzing SQL Server Execution Plans?

SQL Solutions Group helps organizations analyze SQL Server execution plans to identify inefficient queries, indexing opportunities, and performance bottlenecks. Our consultants combine execution plan analysis with other diagnostic techniques to improve query performance and overall database efficiency.

The post What Are SQL Server Execution Plans? appeared first on SQL Solutions Group.

Unlike traditional monitoring tools that provide only a snapshot of current activity, Query Store allows administrators to compare query performance over time and determine when and why performance changed.

What Information Does Query Store Capture?

Query Store automatically collects valuable performance data, including:

• Query execution history
• Execution plans
• Runtime statistics
• Query duration
• CPU time
• Logical reads and writes
• Performance trends over time

This historical data helps administrators investigate issues that may no longer be occurring when troubleshooting begins.

Why Is Query Store Important?

Query Store simplifies SQL Server performance troubleshooting by preserving historical performance information.

It can help identify:

• Queries that have become slower over time
• Execution plan changes
• Performance regressions
• Resource-intensive queries
• Workload trends
• The impact of application or database changes

Rather than relying on guesswork, administrators can use Query Store to compare current performance against previous execution history.

When Should You Use Query Store?

Query Store is valuable whenever you’re investigating SQL Server performance problems or monitoring ongoing database health.

Common use cases include:

• Troubleshooting slow queries
• Investigating performance regressions
• Evaluating application updates
• Monitoring workload changes
• Verifying the impact of tuning efforts
• Identifying frequently executed queries

Many organizations enable Query Store as part of their standard SQL Server monitoring strategy.

Does Query Store Affect Performance?

Query Store introduces a small amount of overhead because it continuously collects and stores performance data. However, for most production environments, the benefits of having historical performance information far outweigh the minimal resource impact. Proper configuration and routine maintenance help ensure Query Store remains an effective diagnostic tool.

How Does Query Store Help Resolve Performance Problems?

By comparing query performance over time, Query Store helps identify when execution plans change, when query performance begins to decline, and which queries consume the most resources. This allows database administrators to focus their optimization efforts where they will have the greatest impact.

Learn More about Query Store

Dealing with some SQL Server performance issues but you’re not exactly sure where the bottleneck is? Struggling to effectively troubleshoot and get things back on track? Sounds like you need to be using Query Store, and we’ll help you get started in this SSG webinar. 

Frequently Asked Questions

Is Query Store enabled by default?

Whether Query Store is enabled by default depends on the version of SQL Server you’re using and how the database was configured. If it isn’t already enabled, administrators can turn it on and configure how much performance history is retained.

What’s the difference between Query Store and wait statistics?

Query Store tracks the performance history of individual queries, while wait statistics measure where SQL Server spends time waiting for resources. Together, they provide a more complete picture of database performance and are often used together when troubleshooting performance issues.

Can Query Store help identify slow queries?

Yes. Query Store makes it easy to identify queries that consume the most resources or whose performance has degraded over time. It also preserves historical execution data, allowing administrators to investigate issues that may no longer be occurring.

Can Query Store force an execution plan?

Yes. One of Query Store’s most valuable features is the ability to force a previously successful execution plan if a newer plan causes performance problems. While plan forcing can be an effective temporary solution, the underlying cause of the regression should still be investigated.

How much history does Query Store keep?

Query Store retains historical performance data based on its configuration. Administrators can control how much data is stored, how long it is retained, and when older information is automatically removed to manage storage requirements.

Should every SQL Server database use Query Store?

For most modern SQL Server environments, Query Store is a valuable tool for monitoring and troubleshooting performance. However, configuration should be based on your SQL Server version, workload, and operational requirements to ensure it provides the greatest benefit with minimal overhead.

Related Articles

• What Are SQL Server Wait Statistics?
• What Are SQL Server Execution Plans?
• How Do I Troubleshoot SQL Server Performance Issues?
• Why Is SQL Server Running Slow?

Need Help Using Query Store?

SQL Solutions Group uses Query Store as part of a comprehensive SQL Server performance tuning and troubleshooting process. Our consultants combine Query Store with wait statistics, execution plans, and other diagnostic tools to identify root causes and recommend practical solutions that improve SQL Server performance.

The post What is Query Store in SQL Server? appeared first on SQL Solutions Group.

Rather than identifying a single problem, wait statistics help administrators understand where SQL Server is spending the most time waiting, making them one of the most effective tools for diagnosing performance issues.

What Do Wait Statistics Measure?

Wait statistics track the cumulative time SQL Server spends waiting for various resources.

Common categories include:

• CPU resources
• Disk I/O
• Memory availability
• Locking and blocking
• Network communication
• Parallelism
• TempDB activity

Analyzing these waits helps determine whether performance issues stem from hardware limitations, workload patterns, or database design.

Why Are Wait Statistics Important?

Wait statistics provide an objective view of SQL Server performance.

They can help identify:

• Resource bottlenecks
• Slow storage performance
• Excessive blocking
• Memory pressure
• Inefficient queries
• Parallelism issues
• Overall server health

Rather than relying on assumptions, administrators can use wait statistics to focus on the areas having the greatest impact on performance.

How Do You Analyze Wait Statistics?

Wait statistics should be reviewed as part of an overall performance analysis rather than in isolation.

Common diagnostic tools include:

• Dynamic Management Views (DMVs)
• SQL Server Management Studio (SSMS)
• Performance monitoring solutions
• SQL Server Health Checks

Experienced SQL Server professionals evaluate wait statistics alongside execution plans, Query Store, performance counters, and workload patterns to develop a complete picture of server performance.

Can Wait Statistics Identify Every Performance Problem?

No. While wait statistics are one of the most valuable diagnostic tools available, they are only one piece of the puzzle. Understanding why SQL Server is waiting often requires additional investigation into queries, indexes, application behavior, and server configuration.

For this reason, wait statistics are most effective when combined with other performance analysis techniques.

When Should You Review Wait Statistics?

Wait statistics should be reviewed whenever users report performance problems, after significant workload changes, or as part of routine SQL Server health assessments. Regular monitoring helps identify developing issues before they become major performance bottlenecks.

Dig Deeper into Wait Stats

Wait stats in SQL Server are a powerful diagnostic tool that help you understand where SQL Server is spending time waiting for resources. They can reveal performance bottlenecks in your system, such as slow disk I/O, CPU pressure, lock contention, or inefficient queries. In this webinar, SSG Senior Consultant Rich Benner discusses the value of wait stats and the best practices for using them.

Frequently Asked Questions

What is the most important SQL Server wait type?

There is no single “most important” wait type. The significance of a wait depends on your SQL Server environment, workload, and overall performance profile. Some waits are expected and indicate normal operation, while others may point to resource bottlenecks or inefficient queries. The key is understanding which waits are consuming the most time and why.

How often should I review wait statistics?

Wait statistics should be reviewed whenever users report performance issues, after significant workload or application changes, and as part of routine SQL Server health checks. Regular monitoring can help identify performance trends before they begin affecting users.

Can wait statistics identify slow queries?

Not directly. Wait statistics reveal where SQL Server is spending time waiting, but they don’t identify specific queries. They are most effective when combined with tools such as Query Store, execution plans, and Dynamic Management Views (DMVs) to pinpoint the underlying cause of performance problems.

Should wait statistics be cleared?

Sometimes. Because wait statistics accumulate over time, administrators may clear them before troubleshooting a specific issue or measuring the impact of performance changes. However, they should only be reset with a clear purpose, as doing so removes valuable historical data that can help identify long-term performance trends.

Are wait statistics useful if SQL Server seems to be running normally?

Yes. Reviewing wait statistics during normal operation establishes a performance baseline that can be compared against future workloads. Having a baseline makes it easier to recognize abnormal behavior and diagnose performance issues more quickly.

Do wait statistics tell the whole performance story?

No. Wait statistics are one of the most valuable SQL Server diagnostic tools, but they should be evaluated alongside execution plans, Query Store, performance counters, resource utilization, and application behavior. A complete performance assessment considers multiple sources of information before determining the root cause of an issue.

Related Articles

• How Do I Troubleshoot SQL Server Performance Issues?
• Why Is SQL Server Running Slow?
• What Is Query Store?
• What Are SQL Server Execution Plans?

Need Help Diagnosing SQL Server Performance?

SQL Solutions Group uses wait statistics as part of a comprehensive approach to SQL Server performance tuning and troubleshooting. Our consultants analyze wait data alongside other performance metrics to identify root causes and recommend practical solutions that improve database performance and reliability.

The post What are SQL Server Wait Statistics? appeared first on SQL Solutions Group.

Although TempDB is recreated each time SQL Server starts, its configuration and performance play an important role in day-to-day database operations.

What Is TempDB Used For?

SQL Server uses TempDB for many internal processes and user operations.

Common uses include:

• Temporary tables
• Table variables
• Sorting and hashing operations
• Index creation and rebuilds
• Row versioning
• Snapshot isolation
• Query processing workspaces
• Temporary storage for internal SQL Server operations

As database workloads increase, TempDB activity often increases as well.

What Causes TempDB Performance Problems?

Several factors can contribute to TempDB bottlenecks.

Common causes include:

• Too few TempDB data files
• Slow storage performance
• Large sorting or hashing operations
• Excessive use of temporary objects
• Long-running queries
• High levels of concurrent activity
• Poor database or application design

Because many workloads share TempDB, performance issues can quickly impact multiple databases on the same SQL Server instance.

What Are the Signs of TempDB Contention?

Symptoms of TempDB problems may include:

• Slow query performance
• Increased wait times
• High disk activity
• Blocking during heavy workloads
• Performance degradation during maintenance operations
• Intermittent application slowdowns

These symptoms often become more noticeable as the number of users and transactions grows.

How Can TempDB Performance Be Improved?

Improving TempDB performance typically involves a combination of configuration and workload optimization.

Common best practices include:

• Configuring multiple TempDB data files when appropriate
• Placing TempDB on fast storage
• Optimizing inefficient queries
• Reducing unnecessary use of temporary objects
• Monitoring TempDB growth and utilization
• Keeping SQL Server updated with current best practices

The right solution depends on your workload and overall SQL Server environment.

Why Does TempDB Matter?

Because nearly every SQL Server instance relies on TempDB, even small configuration problems can have a significant impact on overall performance. Regular monitoring and proper configuration can help prevent bottlenecks before they begin affecting users and applications.

Want to Learn More TempDB?

TempDB has a significant impact on the overall performance of your SQL Server instance, so understanding its inner workings is beneficial for any DBA. This webinar from SSG digs into the finer points of this key part of SQL Server. 

Frequently Asked Questions

Does every SQL Server instance have a TempDB database?

Yes. Every SQL Server instance includes a TempDB system database. It is recreated each time SQL Server starts and is used for temporary objects, internal operations, sorting, row versioning, and other tasks that support normal database processing.

Can TempDB fill up?

Yes. Large queries, index maintenance, heavy use of temporary tables, or long-running transactions can cause TempDB to grow rapidly. If TempDB runs out of available space, SQL Server operations may fail or experience significant performance degradation.

How many TempDB data files should I use?

The optimal number depends on your SQL Server workload and hardware configuration. Microsoft has updated its recommendations over the years, so there is no universal rule. If TempDB contention exists, adding appropriately sized data files may improve performance, but the configuration should be based on testing and best practices.

Should TempDB be placed on a separate drive?

In many environments, yes. Placing TempDB on fast storage that is separate from user databases can reduce I/O contention and improve overall SQL Server performance, particularly for workloads that rely heavily on sorting, temporary objects, or row versioning.

Does SQL Server automatically clear TempDB?

Yes. TempDB is recreated every time the SQL Server service starts, removing temporary objects and resetting the database. However, administrators should not rely on restarting SQL Server as a routine method for resolving TempDB performance problems.

Can poor TempDB performance slow down SQL Server?

Absolutely. Because SQL Server uses TempDB for many internal operations, bottlenecks in TempDB can affect query performance, maintenance tasks, index operations, and overall responsiveness across multiple databases.

Related Articles

• Why Is SQL Server Running Slow?
• How Do I Troubleshoot SQL Server Performance Issues?
• What Are SQL Server Wait Statistics?
• What Is a SQL Server Health Check?

Need Help Optimizing TempDB?

SQL Solutions Group helps organizations diagnose TempDB bottlenecks and optimize SQL Server performance. Whether you’re experiencing contention, storage issues, or unexplained slowdowns, our consultants can identify the underlying causes and recommend practical solutions that improve overall database performance.

The post What is TempDB in SQL Server? appeared first on SQL Solutions Group.

The key is distinguishing between normal blocking and blocking that negatively impacts business operations.

What Causes SQL Server Blocking?

Blocking occurs when multiple processes attempt to access the same data simultaneously.

Common causes include:

• Long-running transactions
• Large update or delete operations
• Poorly optimized queries
• Missing or inefficient indexes
• Applications holding transactions open too long
• High levels of concurrent activity

Reducing transaction duration and improving query performance often minimizes blocking.

How Can You Tell If Blocking Is a Problem?

While occasional blocking is expected, excessive blocking often produces noticeable symptoms.

Common signs include:

• Slow application response times
• Queries waiting for locks to be released
• Users experiencing intermittent delays
• Timeouts during peak activity
• Increased wait times across the server

Persistent blocking can affect many users, even if only one session is causing the issue.

How Do You Identify Blocking?

SQL Server provides several tools for diagnosing blocking activity.

Common troubleshooting methods include:

• Reviewing wait statistics
• Examining Dynamic Management Views (DMVs)
• Using SQL Server Extended Events
• Monitoring Query Store
• Reviewing blocking session information

These tools help identify which sessions are waiting, which sessions are blocking, and how long the blocking has persisted.

How Can Blocking Be Reduced?

Many blocking issues can be resolved through performance optimization and better transaction management.

Common solutions include:

• Optimizing slow queries
• Creating or improving indexes
• Keeping transactions as short as possible
• Scheduling large maintenance operations during off-hours
• Reviewing application transaction design
• Updating statistics and performing regular maintenance

The best solution depends on the underlying cause rather than the blocking itself.

What’s the Difference Between Blocking and Deadlocks?

Blocking occurs when one session waits for another to finish using a resource. A deadlock occurs when two or more sessions each wait for resources held by the other, preventing either transaction from continuing. When SQL Server detects a deadlock, it automatically terminates one transaction so the other can proceed.

Want to Learn More About SQL Server Blocks, Locks, and Deadlocks?

If you’d like a deeper technical dive into how deadlocks occur, watch this webinar from SSG Founder Randy Knight. With useful demos and an engaging style, Randy shows you how to minimize blocking and how locking is normal, blocking is normal (if not excessive), and deadlocks, like a zombie, aren’t normal. 

Frequently Asked Questions

Is SQL Server blocking always a problem?

No. Blocking is a normal part of SQL Server’s locking mechanism, which helps maintain data integrity when multiple users access the same data. It becomes a problem when blocking is prolonged or frequent enough to slow applications or prevent users from completing their work.

What causes SQL Server blocking?

Blocking commonly occurs when one transaction holds a lock while another transaction needs access to the same data. Long-running transactions, inefficient queries, missing indexes, and poor application design can all increase the likelihood of blocking.

How can I identify blocking in SQL Server?

SQL Server provides several tools for identifying blocking, including Dynamic Management Views (DMVs), Extended Events, Activity Monitor, and SQL Server Management Studio. Monitoring wait statistics and reviewing blocking chains can help determine which sessions are causing delays.

What’s the difference between blocking and deadlocks?

Blocking occurs when one process waits for another process to release a resource. A deadlock occurs when two or more processes wait on each other indefinitely, forcing SQL Server to terminate one of the transactions to resolve the conflict.

Can indexing help reduce blocking?

Yes. Well-designed indexes can reduce the amount of data SQL Server must scan, allowing transactions to complete more quickly and hold locks for a shorter period. While indexing does not eliminate blocking, it can significantly reduce its frequency and duration.

When should I investigate SQL Server blocking?

Blocking should be investigated if users experience slow response times, long-running transactions, application timeouts, or recurring performance issues. Persistent blocking often indicates an underlying performance or application design problem that should be addressed.

Related Articles

• What Is a SQL Server Deadlock?
• Why Is SQL Server Running Slow?
• How Do I Troubleshoot SQL Server Performance Issues?
• What Are SQL Server Wait Statistics?

Need Help Resolving SQL Server Blocking?

SQL Solutions Group helps organizations identify and resolve SQL Server blocking issues that affect application performance. Our consultants use proven diagnostic techniques to pinpoint the root cause, reduce contention, and improve overall database responsiveness.

The post What is SQL Server Blocking? appeared first on SQL Solutions Group.