In this brave, new world of Extended Events (XE, XEvents), I find myself with a mixture of scripts for troubleshooting issues – some use XE, and some use traces. We’ve all been told that XE is a much better system (it is much more lightweight, causing less of an issue with the server). In fact, it is so much better that Microsoft has deprecated SQL Trace and SQL Profiler, and in the future, one will not be able to run any traces at all. Believe it or not, this is a good thing!
It just so happens that today is the 67th installment of the monthly T-SQL Tuesday blogging event. T-SQL Tuesday, that wonderful monthly blogging party started by Adam Machanic where a selected host challenges the SQL Server universe to have a blog post about a specific topic. This wild frenzy of SQL Server blog posting occurs on the second Tuesday of each month. This month, it is being hosted by my friend (and the person with the highest amount of energy known to mankind) Jes Borland (b / t), and the topic that she has chosen is Extended Events. Her specific challenge to the SQL Server universe is:
I want to know (and others do, too) how you’ve solved problems with Extended Events. What sessions have you created? What unique way have you used predicates or targets? What challenges have you overcome?
The biggest challenge that I have is not a technical challenge… it’s a personal challenge: actually getting started with XE. I have so many scripts for doing traces, that I just immediately use them instead of the better XE system. I really need to wean myself off of using Profiler / traces. Therefore, I’ve decided to start converting my trace scripts into XE scripts, and I’ll share with you how I go about doing it. Today, I’m going to look at my favorite trace script – a trace to capture deadlock information.
You can read the rest of this article over here.
Hi,
Interesting article, but You are making two assumptions that I find difficult to accept: 1) that you are the only thing that is operating on the database (most of the time, it is other application’s code that is causing the problem and it is the responsibility of my code to be able to dodge the problems that it creates, and 2) that the error itself is the problem – the error is the snowball at the bottom of the hill. The problem that needs to be fixed was 3,000 SQL Statements before the error occurred. It is required that you look at all of them to be able to fix the error, not just handle the error. Handling the error is putting a bandage on the cancer.
I am going to be blunt here. I approved this comment only to hopefully clarify this comment if it is a legitimate comment. As currently composed it makes absolutely no sense. The article is discussing converting server side traces to extended events sessions. This article does not discuss either of the two talking points you have raised.
So how can you disagree with this article based on the two talking points you have proposed?