Performance on Rudi Bruchez

Identify blocking problems

Fri, 28 Aug 2026 00:00:00 +0000

TL;DR

Blocking happens when one session waits for a lock held by another session. To find out who blocks what, you enable the blocked process threshold and start an Extended Events session that records a report every time a block exceeds that threshold. You let it run for a few days, compress the .xel files and send them for analysis. The impact on production is negligible.

This page is a procedure to follow from start to finish. If you are in a hurry, the five steps are: set the threshold, create the session, let it run, collect the files, clean up.

Use ABORT_QUERY_EXECUTION to block query execution in SQL Server 2025

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

ABORT_QUERY_EXECUTION is a new query hint (SQL Server 2025 / 17.x) designed as an emergency brake: it blocks future executions of a query you have identified as a problem — excessive CPU or I/O consumption, a runaway query, non-essential reporting that endangers a critical workload, and so on.

Added as a query hint, it makes the query fail immediately.

Its real value in production comes from combining it with a Query Store Hint: you can block one specific query, identified by its query_id in the Query Store, without touching the application code.

Fix cardinality estimator problems

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

Execution plans define the strategy used to run a query, and are built by the query optimizer. That optimizer is cost-based: to do a good job, it has to estimate the volume of data the query will handle, which is called cardinality estimation¹.

Getting that estimate right matters. A bad estimate produces a bad plan, and very poor performance.

Cardinality estimation rests on two pillars:

statistics, which must be updated regularly;
the Cardinality Estimator (CE), which estimates the complex cases from heuristics — that is, from assumptions.

The CE heuristics were largely implemented in SQL Server 7, in the late 1990s. They were completely reworked in SQL Server 2014, and that reworked version is what people call the new CE.

Get an execution plan

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

Every query is optimized by the SQL Server query optimizer, which builds an execution plan — also called a query plan — to decide the strategy the execution engine will follow.

Looking at that plan is how you find opportunities to optimize a query.

There are two of them:

the estimated plan, more accurately described as the plan before execution;
the actual plan, more accurately described as the plan after execution.

Estimated plan

Display the plan before execution by selecting a query in SSMS and pressing Ctrl+L.
You can also use this button in the SSMS toolbar.

Fix implicit conversions

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

The problem with implicit conversions

Implicit conversions happen when SQL Server has to convert one data type into another in order to perform an operation.

For example, if you compare a VARCHAR column with an NVARCHAR value, SQL Server has to convert the column value to NVARCHAR before it can make the comparison.

That can turn a fast index seek into a full table scan.

Here is a query that causes the problem:

Optimize SQL queries

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

What methodology can you use to optimize your Transact-SQL queries?

Hypotheses

Query performance problems can come from:

A bad data model;
Badly written queries that run too long;
Row-at-a-time rather than set-based behaviour (RBAR);
Trigger execution, or transactions that run too long;
Missing indexes;
Waits, on query parallelism for instance;
Execution plan, compilation and parameter sniffing problems.

A bad data model

A bad data model is hard to fix. You can:

Enable and use the Query Store

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

The Query Store is a SQL Server feature, available since the 2016 version, that keeps and aggregates query performance information.

TL;DR

Enable the Query Store on all your databases. It is an essential tool for diagnosing performance problems, and its impact on performance is negligible. Leaving it off means giving up the information you need to understand and fix execution plan regressions.

Enable the Query Store

You can enable the Query Store, or check that it is already enabled, from the database properties.

Read Committed Snapshot

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

The Read Committed Snapshot Isolation (RCSI) option removes blocking between reads and writes in a database, by switching to an optimistic concurrency model based on row versioning.

Enable it with T-SQL rather than through the SSMS interface. The activation needs exclusive access to the database, and the ROLLBACK IMMEDIATE option below disconnects every user from the database. Plan it accordingly with the application owners.

USE [master]
GO
ALTER DATABASE [<database>]
SET READ_COMMITTED_SNAPSHOT ON
WITH ROLLBACK IMMEDIATE
GO

Replace <database> with the name of your database.

Troubleshoot performance problems

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

If your SQL Server is slow, you absolutely must gather evidence, so that you do not assume problems — and solutions — that have nothing to do with the actual issue.

If you were a doctor, would you prescribe a treatment without making a diagnosis first?

Hypotheses

Where can performance problems come from?

An undersized server;
Bad configuration of SQL Server or of the databases;
Badly written queries that run too long;
Excessive round trips between the client and the server;
Blocking caused by too much locking;
Trigger execution, or transactions that run too long;
Missing indexes;
Waits, on query parallelism for instance;
The client code, rather than SQL Server itself;
Execution plan, compilation and parameter sniffing problems.

How to test the hypotheses

Undersized server

SQL Server runs perfectly well on modest hardware, provided the database and the queries are optimized.

SQL Server Parallelism: Configuring MAXDOP and Cost Threshold

Wed, 28 Jan 2026 00:00:00 +0000

TL;DR

SQL Server’s default parallelism settings are unsuitable for most production environments. Key recommendations to optimize your performance:

Increase the Cost Threshold for Parallelism to 50 to avoid parallelism on small queries.
Set the Max Degree of Parallelism (MAXDOP) to 4 for OLTP workloads, and never exceed 8.
Use Database Scoped Configurations (SQL Server 2016+) to define database-specific settings.

SQL Server can use multiple CPU cores to execute a single query, a technique called parallelism. This can improve performance for heavy queries, but when misconfigured, it can also lead to significant slowdowns and CPU resource contention.