I admit it, I still use SQL Profiler. I always have, and I will for the foreseeable future. My reasons are pretty simple.
- When it comes to troubleshooting I can spin up a Profiler session must faster than an Extended Events session.
- Usually, I’m troubleshooting something as a one-off. so having my session isn’t really something I care about.
- I usually can’t bring scripts into my client’s servers to setup Extended Events, so I have to go create everything manually. (See #1)
- Done correctly with filtering, there’s no risk of a production outage using Profiler.
- If I could bring in scripts to set up an Extended Events session (see #3) I’d have to modify the session which I can do faster in profiler than in Extended Events.
Should you be using Extended Events? Probably. Odds are you got a full-time job somewhere, so extended events sessions are going to make more sense for you as you can run them against your servers and easily jump on and see what the server is doing.
What would it take get me to use Extended Event sessions instead of Profiler? Speed. Whatever GUI Microsoft creates for Extended Events needs to be just as responsive as the Profiler GUI, and the data that is returned needs to be returned by Extended Events just as quickly as data is returned from Profiler.
The post Why Profiler For Life? appeared first on SQL Server with Mr. Denny.
I’m so glad to hear someone; of note say this. I thought it was just me. I have been pounding my head, trying to find a use for XEvents. But speed was always my issue, and not getting the results I wanted on the first pass the way I can with Profiler.
I will continue to learn, and try to use XEvents, but I will also so feeling stupid for returning to Profiler.