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.

A systematic approach helps identify the root cause and prevents unnecessary changes.

Start by Identifying the Symptoms

Before making changes, determine exactly what users are experiencing.

Common symptoms include:

• Slow application response times
• Long-running queries
• Timeouts and failed transactions
• Reports taking longer than expected
• High CPU or memory utilization
• Performance problems occurring only during certain times of day

Understanding when and where performance degrades can narrow the list of possible causes.

Collect Performance Data

Effective troubleshooting relies on data rather than guesswork.

Useful diagnostic tools include:

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

These tools provide insight into query behavior, resource utilization, and system bottlenecks.

Look for Common Performance Bottlenecks

Many SQL Server performance problems can be traced to a handful of common issues.

Examples include:

• Missing or inefficient indexes
• Expensive or poorly written queries
• Blocking and deadlocks
• Outdated statistics
• Index fragmentation
• Memory pressure
• CPU bottlenecks
• Slow storage performance
• TempDB contention

Finding the actual bottleneck is far more effective than applying broad changes across the server.

Evaluate Recent Changes

If performance problems appeared suddenly, consider what changed.

Examples include:

• Application updates
• Database schema changes
• Increased data volume
• New users or workloads
• SQL Server upgrades
• Infrastructure or configuration changes

Identifying a recent change often provides valuable clues during troubleshooting.

Document Findings Before Making Changes

Avoid making multiple changes at once. Document the issue, implement one improvement, and measure the results before moving to the next optimization. This approach makes it easier to determine which changes had the greatest impact and helps avoid introducing new problems.

When Should You Get Expert Help?

If performance problems continue despite routine troubleshooting, a comprehensive SQL Server Health Check can uncover issues that are difficult to identify through day-to-day administration. Experienced SQL Server consultants can analyze performance data, identify root causes, and recommend targeted improvements based on proven best practices.

Frequently Asked Questions

Where should I begin when troubleshooting SQL Server performance?

Start by collecting performance data before making changes. Reviewing wait statistics, Query Store, execution plans, Dynamic Management Views (DMVs), and system resource utilization can help identify the root cause of performance issues rather than relying on guesswork.

What tools are commonly used to troubleshoot SQL Server performance?

SQL Server provides several built-in tools for performance analysis, including Query Store, execution plans, wait statistics, DMVs, Extended Events, and SQL Server Management Studio. Together, these tools help identify inefficient queries, blocking, resource bottlenecks, and other performance issues.

How do I know whether the problem is SQL Server or the application?

Performance issues are not always caused by SQL Server itself. Slow application code, inefficient queries, network latency, storage performance, or infrastructure limitations can all affect response times. A systematic troubleshooting process helps determine where the bottleneck actually exists.

Should I tune queries or add hardware first?

In most cases, it’s best to identify the root cause before investing in additional hardware. Many SQL Server performance issues can be resolved by optimizing queries, improving indexing strategies, updating statistics, or correcting configuration problems.

How long does SQL Server performance troubleshooting take?

Simple issues may be identified and resolved quickly, while complex performance problems involving multiple databases, applications, or infrastructure components can require more extensive analysis. The time required depends on the complexity of the environment and the nature of the issue.

When should I bring in a SQL Server performance expert?

If performance problems persist despite internal troubleshooting, or if business-critical applications are being affected, an experienced SQL Server consultant can help identify bottlenecks, recommend optimization strategies, and reduce the time needed to resolve complex issues.

Related Articles

• Why Is SQL Server Running Slow?
• What Are SQL Server Wait Statistics?
• What Is Query Store?
• What Are SQL Server Execution Plans?

Need Help Troubleshooting SQL Server Performance?

SQL Solutions Group helps organizations diagnose and resolve SQL Server performance issues every day. Whether you’re dealing with slow queries, blocking, resource bottlenecks, or unexplained slowdowns, our consultants can identify the cause and help restore optimal database performance.

The post How Do I Troubleshoot SQL Server Performance Issues? appeared first on SQL Solutions Group.