Comments on: Capturing Transient Query Plan Changes

By: Thomas LaRock

Thomas LaRock — Wed, 15 Aug 2012 00:00:11 +0000

Thanks guys, much appreciated.

By: jonathan

jonathan — Tue, 14 Aug 2012 16:11:25 +0000

The connect item that Joe provides above pretty much sums up the usefulness of Extended Events in capturing the execution plan for query execution. While there are three events that can do this type of operation, sadly they were essentially direct ports from SQL Trace, and simply adding one of them, even with a predicate that prevents the event from ever actually firing, has a 20%+ impact to server performance. I wouldn’t recommend turning these events on to my worst enemy at this point in SQL Server 2012, the level of impact is simply to high to make it worth while. This is incredibly sad because there are some really interesting use cases with some of the complex predicates that are possible in Extended Events, but I’d steer clear for now.

By: joe

joe — Tue, 14 Aug 2012 12:11:15 +0000

Hi Tom,

For SQL Server 2012 there are options. I’m hoping Jon will pop the cork on this (especially being careful of the natural overhead \ danger of capturing the plans – for example – http://connect.microsoft.com/SQLServer/feedback/details/732870/sqlserver-query-post-execution-showplan-performance-impact).

I’ll ping him and get his thoughts on a lightweight approach.

Cheers,

Joe

By: Thomas LaRock

Thomas LaRock — Tue, 14 Aug 2012 11:06:56 +0000

Joe,

Can you use XE to capture the query plan directly, rather than going to the DMV?

Thanks,

Tom