Troubleshooting on Rudi Bruchez

Analyze queries

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

Here is a condensed checklist of the method for analysing the performance of a query, or of a SQL Server database.

1. Look at the I/O — `SET STATISTICS IO ON`

If there is a lot of I/O on a table, is there an index on it? (video, in French)

2. Look at the time — `SET STATISTICS TIME ON`

SET STATISTICS IO, TIME ON (video, in French)
Mind the difference between CPU time and total elapsed time.
CPU < elapsed ⇒ waits. Not the query’s fault: lock blocking, disk reads, or the behaviour of the client’s data reader (video, in French).
CPU > elapsed ⇒ parallelism (video, in French). Not a problem in itself.

3. Look at the actual execution plan

Is there a discrepancy in the cardinality estimate? Under-estimation is the dangerous direction.
Prefer Plan Explorer for reading plans.
If there is a discrepancy, update the statistics (video, and this one for updating them from the maintenance plan — both in French).
It could be a table variable: if so, use OPTION (RECOMPILE), or SQL Server 2017 and later.
It could be the Cardinality Estimator itself.
- On a cardinality estimation error in a complex query, experiment with the CE version.
- OPTION (USE HINT('FORCE_LEGACY_CARDINALITY_ESTIMATION'))
- OPTION (USE HINT('ASSUME_JOIN_PREDICATE_DEPENDS_ON_FILTERS'))
- OPTION (USE HINT('FORCE_DEFAULT_CARDINALITY_ESTIMATION'))
- ALTER DATABASE SCOPED CONFIGURATION SET LEGACY_CARDINALITY_ESTIMATION = ON;

4. Analyse performance across the whole workload

Use Extended Events, filtering on duration.
Use Extended Events with no filter for a short while, to see whether there are repetitive or duplicated queries.
Look at the query statistics: dm_exec_query_stats.

Use the Query Store (SQL Server 2016 and later)

DataFrogs session — Nicolas Souquet, Tout savoir sur le Query Store (in French)
DataFrogs session — Query Store, bientôt incontournable (in French)

Extract deadlock information

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

A deadlock happens when two or more processes block each other in a cycle while trying to access the same resources in the database. When that happens, SQL Server picks one of the processes as the victim and kills it, which lets the others get to the resources they were competing for.

When a deadlock occurs on a SQL Server, you need to diagnose what caused it.

SQL Server raises an event whenever a deadlock occurs and a victim is chosen. That event is automatically stored in an event session — a trace, if you prefer. The information it stores is called the deadlock graph, an XML representation of the situation. SQL Server Management Studio (SSMS) can display it as a diagram.

Retrieve the error logs

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

To analyse problems on a SQL Server instance, retrieve the SQL Server error logs (ERRORLOG). They hold a great deal of useful information.

Retrieve the logs

The error logs are text files, in a specific directory under the SQL Server data folder.

You can find its path with this query:

SELECT SERVERPROPERTY('ErrorLogFileName');

There you will find ERRORLOG, the current log, and the ERRORLOG.* files, where * is a number. After a rotation — usually at instance restart — the previous log becomes number 1, the one before it number 2, and so on.

Identify excessive memory grants

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

When an execution plan has to sort, or to build a hash table in memory, the query optimizer has to work out how much memory to reserve for those operations.

Take this query as an example.

SELECT *
FROM Contact.Contact c
ORDER BY c.LastName, c.FirstName;

SQL Server has to reserve enough memory to hold the whole table — SELECT * asks for everything — and perform the sort.

The estimate of how much memory to reserve depends on the cardinality estimate and on the size of the data. A bad estimate therefore has two possible causes:

Use sp_whoisactive to see the active queries

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

sp_whoisactive is Adam Machanic’s stored procedure. It shows what is running on an instance right now, in a far more readable form than sp_who2.

Useful parameters

@get_plans — tinyint, 0 (default) or 1. Set to 1 to include the query plan in the output.
@find_block_leaders — bit, 0 by default. Set to 1 to identify the sessions at the head of a blocking chain, and the number of sessions each one blocks.
@get_memory_info — exposes the memory grant information for the query.
@get_query_stats — exposes the query execution statistics.

Trace execution plans

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

To follow what an application or a batch process really does, it helps to capture the actual execution plans — the plans after execution — of the queries it runs.

Extended Events can do that.

Actual execution plans can be captured with no noticeable performance impact thanks to the lightweight profiling infrastructure, on SQL Server 2017 from CU21 onwards, and on SQL Server 2019 and later.

Create the event session

Run the following on your server. It creates the session without starting it, so there is no impact yet.

Detect an active transaction

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

DBCC SQLPERF (LOGSPACE)

SELECT name, log_reuse_wait_desc
FROM sys.databases

DBCC OPENTRAN

EXEC sp_who2

DBCC INPUTBUFFER (51)

KILL 71

Troubleshooting on Rudi Bruchez

Analyze queries

1. Look at the I/O — SET STATISTICS IO ON

2. Look at the time — SET STATISTICS TIME ON

3. Look at the actual execution plan

4. Analyse performance across the whole workload

Use the Query Store (SQL Server 2016 and later)

Extract deadlock information

Retrieve the error logs

Retrieve the logs

Identify excessive memory grants

Use sp_whoisactive to see the active queries

Useful parameters

Trace execution plans

Create the event session

Detect an active transaction

1. Look at the I/O — `SET STATISTICS IO ON`

2. Look at the time — `SET STATISTICS TIME ON`