This one isn’t bad, but imagine a multi-statement deadlock, or a server with several deadlocks in an hour – how do you easily see if there were other errors on the server at the same time?
With SQL Server 2012+, we have a better tool to see when deadlocks occur – and the deadlock graphs are saved by default, so we don’t have to read the text version to figure it out, or run a separate trace to capture them.
In SSMS, open Object Explorer and navigate to Extended Events > Sessions > system_health > package0.event_file. Double-click to view the data.
Click through for the entire process.
Grant Fritchey notices something odd about execution plans grabbed from an Extended Events session:
Notice anything missing? Yeah, the first operator, the SELECT operator (technically, not really an operator, but they don’t have any name or designation in the official documentation, so I’m calling them operators). It’s not there. Why do I care?
Because it’s where all the information about the plan itself is stored. Stuff like, Cached Plan Size, Compile Time, Optimizer Statistics Usage, Reason for Early Termination, is all there, properties and details about the plan itself. Now, the weird thing is, if you look to the XML, as shown here, all that data is available:
Read on for Grant’s best guess as to the root cause of the problem.
The AlwaysOn_health event session in Extended Events is intended to make analyzing problems with Availability Groups possible after they have occurred. While this event session goes a long way towards making it possible to piece together the puzzle of what went wrong in a lot of situations, it can still be a difficult task. One of the things I wish Microsoft had included in the AlwaysON_health event session definition is the sqlserver.server_instance_name action for every event, and this is something that I usually recommend clients add to each of their AG servers using a script after I work with them the first time. Why would this be useful, since if the files come from a specific server we should know the events are for that server right? Well, when we are working with AG configurations with more than two servers and trying to see the big picture of what is happening across the servers, it can be difficult to follow timelines with multiple files from multiple servers open. It’s not impossible, but it does make things more difficult.
Click through to see how to do this through the UI or via T-SQL.
Chrissy LeMaire solves a bunch of common problems with Extended Events:
So why do people keep using traces? We compiled a list of reasons from Erin Stellato’s Why do YOU avoid Extended Events. And this list is LONG!
- Traces are straightforward and less complex than Extended Events
Totally seems that way!- Traces provide a consistent interface for mixed environments
Whether you use SQL Server 7 or SQL Server 2017, the interface is pretty much the same.- Traces are faster to setup quick traces
Just open up Profiler, connect to a server, click a few times and you’re set.- “Extended Events are more efficient for the SQL Server engine, but not more efficient for the DBA”
Love this quote.- People already have a library of Profiler templates
Including me- Ignorance of XML / Querying all the generated XML is outrageous
When I first saw what it takes to query Extended Events, I bailed immediately. I am not learning XPATH, ever.- Templates work remotely across all instances
This is also true for Extended Events, but the commenter did not know that.- XEvents are persistent and must be stopped manually
Once you close Profiler or restart SQL Server, all non-default traces will disappear. Extended Events will persist until you delete them.- Ability to import PerfMon data and look at Trace and PerfMon counter data at the same time
Most people that use Profiler don’t seem to know about this feature but those who do LOVE it. You can read more at Brad McGehee’s Correlating SQL Server Profiler with Performance Monitor.Microsoft reportedly has no plans to provide this functionality.
- Consistent user experience across SSAS and Database Engine
Gotta take their word, I don’t use SSAS.- It’s easy to train others to use Profiler
Imagine – if it’s easier to learn Profiler, it’ll be far easier to teach.- Traces can be easily replayed
There are a number of Microsoft tools to replay traces, but none to replay Extended Events.- MS Premier Support still asks for traces
Likely because they also have tools that they want to work across all supported versions, which still includes SQL Server 2008 R2.- xe_file_target_read_file is a CPU hog
This wasn’t listed on Erin’s page but was told to me while I was performing my research.Whewf! That’s a lot of compelling reasons not to make the switch. So let’s see how we can address each of them using PowerShell. All code listed here can be found at sqlps.io/xecode.
Chrissy & co can’t solve all of them, but they solve a majority. Click through to see how.
Jason Brimhall shows how Extended Events and server trace events (like Profiler uses) map together:
If you have browsed XEvents to any extent you should probably be familiar with at least one map object that Microsoft has given us. That particular object is sys.dm_xe_map_values and I wrote a bit about it here. That object presents some good information about various data values within XEvents that are delivered with the Event payload as well as some hidden gems that can be extra useful for exploring SQL Server internals. The point is, maps is not necessarily a new concept.
While the concept of a map is not new within XEvents, the implementation in this case is a tad different. You see, the dm_xe_map_values object is more like an EAV object while the map I will introduce today is more of an ordinary lookup table. Let’s take a look.
The map I want to concentrate on for now is the sys.trace_xe_event_map table. You read that correctly – it is a table. We don’t have very many “tables” when dealing with XEvents, but this one happens to be. As Microsoft Docs describes it, the table “contains one row for each Extended Events event that is mapped to a SQL Trace event class.”
Click through for a script which shows how to map them, as well as a couple interesting points.
Derik Hammer has a few useful extended events sessions that he’s sharing with us:
Extended Events are the all-around smart choice. They take a little bit of time to get used to, however. With thousands of new events and data points, it can be difficult to create an event session in a pinch. That is why it is important to have event sessions pre-scripted or pre-implemented on your SQL Server instances. A little bit of up-front work can save you a lot of time when you need information on the spot. Having them pre-scripted also prevents you from jumping back to Profiler, which has a much heavier footprint on your server.
When I create Extended Event sessions, I tend to use the SQL Server Management Studio wizard to find the events and actions (additional fields) that I want. Then, I will script it out and save it for later.
Below are five Extended Events sessions that I have found particularly useful and recommend you add to your toolbox.
Click through for all of those scripts, as well as queries to shred the resulting XML.
Gianluca Sartori introduces a new tool to help with event handling in SQL Server:
I am proud to introduce XESmartTarget: the easiest way to interact with extended events sessions without writing a single line of code.
XESmartTarget uses the Extended Events streaming API to connect to a session and execute some actions in response to each event. The actions you perform can be configured in a simple .json file, which controls the Response types and all their properties.
For instance, if you have a session to capture deadlocks, you may want to be notified whenever such an event is captured. All you need to do is configure XESmartTarget to send an email using the EmailResponse class. You can do that by creating a simple .json file with all the parameters needed
This looks quite interesting.
Marek Masko shows off the new Extended Events Profiler In SQL Server Management Studio 17.3:
XE Profiler looks promising and can be really a great feature. We can use it with no issues on any version of SQL Server which supports extended events – not only with newest SQL Server 2017. I tested it with SQL Server 2014 and it was working well. Currently, lack of configuration of new templates, and logic based on hard-coded names is the biggest concern and discomfort for the user. However Microsoft didn’t officially release yet this version of SQL Server Management Studio, so it’s hard to say what will be the final feature functionality.
I’m hoping that when the final version appears, it will be good enough to get people finally to kick the Profiler habit.
Erik Darling unwraps some of his Christmas presents a bit early:
There are, as of RC2 being released, 194(!) new Events to Extend your mind with. Not all of them are interesting to me, and I haven’t had time to pry into all of the ones that are interesting just yet.
This is a rundown of the new Events with names or descriptions that I found interesting, and will try to spend some time with.
I can’t promise anything
After all, getting some of these to fire is tougher than using a Debugger.
There are some interesting events here.
So what is the solution? Well it really depends. But the solution I wrote walks you through
Setting the default fill factor
Tracking page splits
Lowering the fill factor
Read on to learn more.
Kevin Feasel
2018-04-25
Extended Events, Locks, Blocks, and Deadlocks
No Comment