Question: How to Find Running SQL Trace? Once we know the trace exists, how to stop and delete them?
To tell you the truth, I didn’t know how to start this article about SQL Profiler vs Extended Events. After all, I decided to take mind off things and to watch a movie. The movie was Iron Man 2. In addition to the brilliant performance of Robert Downie Jr., one phrase stuck in my mind and immediately inspired my writing.
“Don’t get so attached to things, learn to let go.”
~ Iron Man 2 (Robert Downie Jr)
What is better the old reliable SQL Profiler or something new? My personal choice is Extended Events. Why? To deal with Extended Events, we should go back to SQL Profiler and comprehend its work. First, a new trace is created, and information to be traced is noted.
One of the most sought after blog is around Wait Stats when it comes to performance troubleshooting. The place to bookmark would be – SQL SERVER – Wait Stats – Wait Types – Wait Queues – Day 0 of 28. I get queries from a number of you and have been fortunate in the past for sending me such information because it becomes a great learning experience for me too. At the same time, your problems are getting solved too. It becomes a great win-win situation. Let us learn about Extended Event wait_info in this blog post.
In the recent past, I have written a number of posts around ColumnStore Index and how they function. Some of the nuances of working with ColumnStore Indexes are available in this blog for reference. I have also written a few posts around Extended Events. One of my DBA friends pinged me to check if there were any way to use Profiler to see how ColumnStore Indexes worked. Obviously, there was nothing much of help I could offer because there were actually none in reality.