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.
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
- 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.
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.
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.
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.
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.
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.
There was a question in dba.stackexchange.com titled “module_end extended events duration in microseconds?” that I answered and it was Microsecond in that instance.
Later on I questioned myself if the duration is always in Microseconds for extended events. I found, it is a mix of Millisecond, Microsecond and some are unknown meaning famous NULL. I wrote below tsql code to determine which is what.
Click through for the script that Taiob used to determine the answer.
Now that the extended events session is setup we can use some queries to query information about our AGs and error messages happening on our servers. First to query when the server failover and becomes your primary server query the event availability_replica_state_change. The first 10 lines just read in the files for the extended event session so you don’t have to identify the exact filenames. Then we parse the xml event for get the timestamp, previous state, current state, repliace name, and group name for the event FROM the filenames we collected before. In the WHERE clause were are looking for when the state has changed to PRIMARY_NORMAL indicating a failover to the server.
Read on for scripts showing what she extends and also how to query this data.