Targeting Wait Statistics with Extended Events David Maxwell

Obligatory Bio Slide David M Maxwell, SQL Server Consultant for UpSearch Twitter: @dmmaxwell or @UpSearchSQL Email: dmmaxwell@gmail.com or david.maxwell@upsearch.com Web: dmmaxwell.wordpress.com or upsearch.com Visit https://upsearch.com/connect-with-us and find your ideal way to stay in touch.

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.

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 2005. 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.

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.

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.

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

Demo Time!

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

Thank You! Thanks for your time. Twitter: @dmmaxwell or @UpSearchSQL Email: dmmaxwell@gmail.com or david.maxwell@upsearch.com Web: dmmaxwell.wordpress.com or upsearch.com