1. Targeting Wait Statistics with Extended Events
David Maxwell

2. Obligatory Bio Slide
David M Maxwell, SQL Server Consultant for UpSearch or Web: dmmaxwell.wordpress.com or upsearch.com Visit and find your ideal way to stay in touch.

3. Overview of Technologies Involved Assembling the Solution
Agenda
Overview of Technologies Involved
Assembling the Solution
Demonstrations
Today we’ll be looking at how to target wait stats for performance troubleshooting using Extended Events, in a few different ways. We’ll start with a quick review and discussion of wait statistics and what they are and are not good at. We will take a quick look at some of the dynamic management views available for examining wait stats, including DMVs that are only available in SQL 2016 and above. Then we’ll turn our attention to Extended Events, available in all supported versions of SQL Server, and how they can be used to extract information on wait statistics.
We’ll continue with a discussion of how to assemble a solution for monitoring a workload, and seeing what waits are being generated at several levels, from individual queries or sessions, all the way up to databases, multi-database workloads, and beyond.
Once we’ve finished our overview, we’ll walk through a few example scenarios and I’ll show you how it all comes together.

4. Wait Statistics – The Good, and the Not-So-Good…
Performance Troubleshooting Go-To
Available in SQL Server or via Perfmon (Sort of…)
Can be hard to weed out false positives
Can be hard to determine source of individual waits
Wait statistics have been a go-to performance troubleshooting tool since they were first introduced in SQL Server Wait stats are great at showing what resources are being most frequently requested, both within the operating system, and within SQL Server. Everything from CPU and RAM, all the way to specific page latches, Wait stats are an excellent way to determine why your server isn’t running as quick as you think it should.
Wait statistics can be gathered either directly from within SQL Server by queries, or by using Performance Monitor. SQL Server currently tracks almost 900 different waits within it’s DMVs. Perfmon has access to 12 of them, so it’s not an even comparison. You can still get some decent information on basic resource usage, but it’s in no way complete.
Now speaking of the number of wait stats SQL server tracks, it should be noted that not all wait stats are created equal. Of over 900 different wait stats, many are only notable in specific situations, or for specific features like In-Memory processing or High-Availability configurations. In fact, most queries that people have written to examine wait statistics pre-emptively remove or ignore certain types of waits that are always present in the results. Many of these are background processes, which aren’t really bothersome when it comes to SQL Server performance.
Over time SQL Server has tracked more and more types of waits as features were added to it. However, it wasn’t until SQL Server 2016 that we got a DMV that allowed us to look at Wait Statistics at more than just the instance level. Sure, there are third party tools that could extract that information, but not everyone has the budget for third party tools.

5. Wait Statistics – Dynamic Management Views
sys.dm_os_wait_stats, sys.dm_os_waiting_tasks (Since 2005)
sys.dm_exec_session_wait_stats (Since 2016)
Persisted only for the life of the session
Snapshot methods – not good for trending
Good for performance tuning individual queries or sessions
SQL Server tracks both accumulated wait stats and currently waiting tasks at the server level in a set of DMVs, and has done so since the beginning. Those are dm_os_wait_stats and dm_os_waiting_tasks. In 2016 SQL Server introduced a new DMV dm_exec_session_wait_stats that showed wait statistics at the session level, which was a good step forward. The stats gathered in this table are only persisted for the life of the session, so when a session disconnects, the statistics are dropped. That makes this DMV good for a few things. This is good for getting a point-in-time snapshot of the accumulated waits for current sessions on your system. It’s easily joined back to other DMVs to get additional information about those sessions such as user, application and database. But the short life of the information makes it difficult to get long-term information on more than simple workloads. You can, however, use this DMV to get wait info for performance tuning of individual queries or sessions.

6. Wait Statistics – Extended Events
Extended Events – helping performance tuners since 2008
Running trace of events, including wait information
Capture and examine, like profiler
Good for workload profiling, but not immediate troubleshooting
Requires Xquery to read output
To get comprehensive information for wait stats, in a way that allows for more efficient analysis, we turn to Extended Events. Extended Events have been around since SQL Server 2008 R2, and are a much more efficient replacement for Profiler. In an extended events trace, wait statistics information can be gathered simultaneously with sql text, query plans, and a large amount of other information. Info can be gathered from a level as granular as an individual session, all the way up to an entire instance. XE sessions are like profiler in the sense that they can be watched live, but are best when captured and examined later. This is for getting a larger picture and a breakdown of what your workloads are waiting for, rather than what individual sessions are waiting for. And, they’re available in most supported versions of SQL Server.

7. Assembling The Solution
Querying the XE DMVs
Creating the XE Session
Filtering
Reading the output
Automation

8. Demo Time!

9. Wait Stats show inefficient use of resources
Summary
Wait Stats show inefficient use of resources
Extended Events allows for granular capture of events
Consider your goal – snapshot or profile?
Assemble and save your solution
Automation is key

10. Thank You!
Thanks for your time. or Web: dmmaxwell.wordpress.com or upsearch.com