What Are the Most Common Blockers to Adopting SQL Server Extended Events?

Yeah, stupid long title. It’s a question I put to several different AI engines. I’m curious what the aggregated knowledge of the internet has to say on the topic of blockers to Extended Events adoption. I’ll leave it to you to do the search on your favorite engine and get the wordy, long-winded, answers. However, I want to bring up some of the points that were raised in order to talk about them. First, we’ll talk about some of the odd answers. Then, we’ll talk about the consensus. Also, one engine gave me a blatantly poor example Session, so I want to point that out.

Note: I’m not dinging on AIs. I’m growing to like the little monsters. We’re going to address valid points that they bring up. However, I also don’t want to shy away from pointing out, “trust but verify” need to be your watch words when dealing with these things.

Odd Answers?

There were a lot of common themes among the AI engines on which I tested the question about blockers to Extended Events adoption. Oh, before we continue, these are the engines I used:

• Perplexity
• Gemini
• Brave.AI
• ChatGPT
• You.com
• CoPilot

There were differences across all the engines, but there was a lot the same. A couple of unique ones that I found interesting/perplexing were:

• Perplexity: Limited Visibility into Application Behavior: Well, yeah, it’s a server-side monitoring tool. If this is your blocker, you’re doing it wrong.
• Brave: Lack of Visibility into Query Performance: WHAT? Yeah, somehow that engine thinks that Extended Events can’t really show you what’s happening with your queries. In fact, if anything, it’s going to give you too much information. That’s a weird one.
• ChatGPT: Toolchain Compatibility: Meaning, integration with other tools. I’m assuming stuff like 3rd party monitoring. Another odd one because the major tool vendors are using Extended Events (ask me how I know).
• ChatGPT: Permissions Management: Huh? It runs within the context of the server. That’s it. Worst thing, where do we output the data to and what are the permissions to access that. But, come on. Weird one.

With the exception of the bad example, I didn’t see anything that I didn’t expect to see. Let me know in the comments if you disagree and these suggestions are actually blockers to Extended Events adoption for you.

Blockers to Extended Events Adoption

Each of the AIs provided a different list, but there were some very common themes to what the blockers to Extended Events adoption truly are. I’m going to summarize some. I’m also going to leave some off. And some of the AIs had interesting additions that I may drill down on in the future. Let’s hit the list (in no particular order):

• Familiarity: OK, so I said no particular order, but I want to put this one first because it made every single list. In fact, it’s one of only three points that was on every list. And yeah, I agree. This is THE blocker. Whether we’re talking familiarity, and comfort, with Trace, or just a lack of familiarity with Extended Events, this is a major blocker. It also encompasses resistance to change and not enough time to learn new methods. It’s the one I’ve always focused on to try to get people on board.
• Lack of Tooling: Yeah, this one I get too. We do have tools though. SSMS has the Data Explorer window, which, granted, has a bit of a learning curve, but not that much. We also have the, glorious, DBA Tools, which will allow you to automate your access & control over extended events through Powershell. We’ve also got the fantastic work by Gianluca Sartori on XESmartTarget and others. But yeah. Once more, I’ve focused here to try to help.
• Performance Concerns: I won’t lie about it. This one surprised me a little. Can you crush a system with Extended Events? Yes. Can you do that more easily than with Trace? OK, get into some of the debug events, yeah, sure, but, you know, don’t do that. Can you with standard events? No. In fact, Extended Events are generally better citizens within SQL Server than Trace events are, by a long shot.
• XML: ‘Nough said. I hate it too. Course, you could avoid it, or embrace it.
• Event Overload: This is one I hadn’t honestly thought about. I tend to look at the insanely long list of events as a benefit. But, I’m wrong. That insanely long list is information overload. Which one do you pick? When? How? Why? Documentation on some of the events is non-existent. Others won’t work without a secret switch from Microsoft. For example, the majority of Query Store events, don’t do anything that I can see from my testing. Lots of testing. So, yeah, this is one we need to focus on because it is truly a blocker to Extended Events adoption. One I didn’t think about appropriately.
• Storage Management: On the one hand, yes, this is a blocker. On the other hand, we had the same problem with Trace, so why would this be harder? But yeah, spitting out 10s of thousands of events an hour, that adds up. I still personally don’t see it as a blocker, but it should be a concern, for certain.
• Lack of Knowledge: Yeah, kind of the same thing as familiarity, but it was separated out as a concept by several of the AIs, so I figured I’d finish where I started. People don’t know that Extended Events even exist. Or, they don’t know what Extended Events can do. Or, they don’t know the unique types of monitoring that Extended Events can offer. There is a lack of knowledge and understanding. Again, it’s one I’ve spent a decade trying to address (I can hear you, “We know, Grant, shut up already”).

There was more, but this gets you to the gist of the problem. My old title at Redgate was Evangelist (still like it better than Advocate). And it fits me. I can be an evangelist when it comes to things I love. I just want to get people to where they see the utility of Extended Events so that they’re willing to try to overcome the blockers to Extended Events adoption.

Oops!

Before we go, one little oopsie from an AI. It’s unclear where this came from, but here’s a suggested Session from Brave.AI:

CREATE EVENT SESSION [MySession] ON SERVER 
ADD EVENT sqlserver.sql_statement_completed(
    ACTION(sqlserver.database_name, sqlserver.sql_text)
    WHERE [database_name] = 'MyDatabase'
);

For those that don’t know, the text of the query is included in sql_statement_completed (not that I would necessarily use this as a start point, I’d be more inclined to sql_batch_completed, but different discussion). So, adding the Action, sql_text, is both redundant, adds to the disk management concerns, and adds some performance overhead that’s unnecessary. The results from Brave.AI included a couple of links, but neither of those had this code in it, so I’m unsure where it came from, but, here we are, trust but verify.

Conclusion

I’m prepping a presentation on AI, so I’ve been using it a lot. Plus, after having the opportunity to sit next to Bob Ward on a plane flight last year, I got a good introduction into the real utility that AI can offer. I’ve been chasing that in my day-to-day work. So, I was sitting here thinking about a block post and I decided, what if I combine two interests. Here we are. I really like the results. There were several things I learned, which is awesome. I also had some ideas reinforced and validated. Equally awesome.

If you have a reason for not using Extended Events that’s not included here, I’d be curious about it. Let me know.

---

If you are interested in learning about Extended Events, I’ll be spending about half a day on them at my all day session at DataSaturday Gothenburg in just a couple of weeks, September 6, 2024. Please join me.