I know, I know, I’m on #teamexevents so I think that Extended Events can do no wrong, but let’s address this thought that Profiler is easier.
Now, if we’re strictly talking knowledge, sure, if you’ve got a lot of experience with Profiler/Trace and very little with Extended Events, of course Profiler is easer. However, what I’m told is that Profiler doesn’t require very much set up, while Extended Events does. That’s just wrong, but let’s put it to the test.
The Test
For the comparison, we’re not going to do anything special with either tool. I’m just going to start collecting query data with the fewest possible clicks and/or key strokes. I’m going to use both tools short cuts to make this as fast as possible. The goal is, click, connect, BOOM, too much data.
If I’ve done this wrong somehow, let me know.
Profiler
The fastest way I know to get Profiler up and running, when you already have SQL Server Management Studio open, is to the use the Tools menu. You could set up quick keys or something like that, but you could do the same with Extended Events, and we’re not doing anything special here.
So, let’s count clicks.
- “Tools” menu
- “SQL Server Profiler” menu choice
- Assuming you’re connecting to the same server as you were connected to in SSMS, click connect (although, here, let’s say you logged in using a SQL login, you may have to type the password, but I’m not going to cheat in any way)
- The default trace of Standard is immediately open. Click Run.
BOOM! That’s it. Four clicks to start gathering to much query information. You have to admit, it’s simple. Let’s see how things go with Extended Events.
Extended Events
I’m starting from the same place. I have SSMS open and I’m connected to a server, exactly like Profiler. Again, the goal here is no unfair advantages.
Let’s count clicks.
- Expand “XEvent Profiler” in the Object Explorer window (open by default, so I’m not cheating here)
- Double click “Standard”
BOOM! Too much data. Three clicks.
Conclusion
Honestly, this comparison is crap. Yay! Extended Events won! Who cares.
The real point here is that there really are a lot of misconceptions about Extended Events. People just don’t know enough about how it works. The biggest point of it is not that it’s a replacement for Profiler. The fact is, it’s MORE than a replacement for Profiler. It’s a massive upgrade to 21 year old technology.
It’s not that it can do the same things as Profiler. It can. It’s not that three versus four clicks matters, it doesn’t. It’s that the things you think you know about Extended Events, just may not be true at all.
I’ll do another blog post soon comparing the ease of actually setting up a customized set of metrics in Profiler vs. Extended Events. I think you’re going to be surprised, again.
If you think this little comparison is remarkable, wait until you see all the things that Extended Events can do for you. I’m putting on an all day seminar that covers Extended Events in detail as well as Query Store, Execution Plans and more at DevIntersection in April:
On the other hand, if you want to talk DevOps, I have an all day class at Bits:
What’s next, “I can name that query plan in 5 notes?” 🙂
Seriously, I do like the post.
Nice post, looking forward to the next one. Still trying to get coworkers to use Extended Events over Profiler.
HA! Thanks. Just trying to clear up all the confusion around extended events. There’s just so much bad info out there.
Who in the world would run a profile on the standard Trace template. the server dumps so much crap out. I always apply some sort of filter whether its a logon, or machine name, etc. The Interface with extended events is not as intuitive. However easy once you realize what to do.
I agree that the interface is not intuitive. It’s not very hard to figure out though.
I also agree that no one should be using the unfiltered trace template. However, I was told that Profiler/Trace was easier because you could, and I quote, “Connect, click, boom, too much data” which is why I used it in the examples. Evidently some people do it that way. I wouldn’t. You wouldn’t. People do.
[…] wrote a short blog post about the misperception that Profiler was easier than Extended Events when it came to the core concept of “click, connect, BOOM, too much […]
OK – fair point, I give in 🙂 , but the “watch events live on screen as they happen” is just not right. it needs fixing to look more like profiler
Did you look at the screen? It’s identical in every possible way to Profiler without actually being Profiler.
Plus, the gui, once you learn it, because, yeah, it’s not intuitive, does a million things that are just impossible in Profiler. I have a ton more stuff I’ll try to get posted on this. It’s a shame I have to get paid and do a job because I could spend full time documenting all the ways that Extended Events are superior to, and easier, than Profiler.
What is the minimum version for SSMS to have this level of access to Extended Events? Many of our workstations still have SSMS for Sql Server 2012, and there is no XEvent Profiler option in the Object Explorer window.
Knowing what the minimum level of SSMS will help us appeal to Management for updates. “If it ain’t broke…”
Pretty sure that was introduced with the 17 version of SSMS. That one supports back to 2012 just fine (it supports back to 2000 based on testing in my company, just not very well, I wouldn’t recommend it for less than 2012).