An Introduction to Wait Statistics in SQL Server 2019

A Hands-On Guide to Using Wait Statics in the Applied Space

Welcome to An Introduction to Wait Statistics in SQL Server 2019

What you’ll learn

  • How to Install SQL Server 2019 and SQL Server Management Studio.
  • How to use wait statistics to troubleshoot real-world problems..
  • How to incorporate wait statistics into sp_whoisactive to see what each transaction is waiting on..
  • How to fix issues you find using wait statistics..

Course Content

  • Introduction –> 11 lectures • 31min.
  • Hands-On Wait Statistics –> 12 lectures • 47min.

An Introduction to Wait Statistics in SQL Server 2019

Requirements

  • A foundation in SQL Server is highly recommended..
  • This is not an entry level SQL Server Course..

Welcome to An Introduction to Wait Statistics in SQL Server 2019

This course is a brief, hands-on approach to using wait statistics in SQL Server. The course will use SQL Server 2019.

The execution of SQL Server’s internal code is done using a mechanism called threads. Each thread can be executing SQL Server code, and multiple threads coordinate together when a query runs in parallel. These threads are created when SQL Server starts, depending on the number of processor cores available for SQL Server to use.

Threads are placed on a scheduler when a query starts, with one scheduler per processor core, and don’t move off that scheduler until the query has finished. A scheduler has three basic ‘parts’:

  1. The processor, which has exactly one thread currently executing code.
  2. The waiter list, which has all the threads that are basically stuck, waiting for a particular resource to become available.
  3. The runnable queue, which has all the threads that are able to execute but are waiting to get on the processor.

Threads transition from state 1 to 2 to 3 to 1, around and around until the query has finished.

From our perspective, the most interesting part of scheduling is when a thread has to wait for a resource before it can continue. Some examples of this are: A thread needs to read a page, and the page isn’t in memory, so the thread issues an asynchronous physical I/O and then has to wait, off the processor, until the I/O completes. A thread needs to acquire a share lock on a row to read it, but another thread already holds a conflicting exclusive lock while it is updating the row.

When a thread encounters the need for a resource that it cannot get, it has no choice but to stop and wait for the resource to become available (the mechanism for how the thread is notified about resource availability is beyond the scope of this article). When that happens, SQL Server makes a note of why the thread had to wait and this is called the wait type. Some examples of this are: When a thread is waiting for a page to be read into memory so it can be read, the wait type is PAGEIOLATCH_SH (if the thread is waiting for a page that it will change, the wait type is PAGEIOLATCH_EX). When a thread is wait for a share lock on a row, the wait type is LCK_M_S (lock-mode-share)

SQL Server also keeps track of how long the thread has to wait. This is called the resource wait time, and is usually just known as the wait time.

Thanks for your interest in An Introduction to Wait Statistics in SQL Server 2019.

See you in the course.