I've got several blog posts on the cost threshold for parallelism. First, we need to make sure you're on the service packs and CUs from the fall (at...

And the delete, while fast, is not free, so it's also adding a little to the time.

Getting exact measures is going to be very hard because, at the root, is the query run more than once with a unique data set each time, or a mixed...

You literally can not go wrong using Paul Randal, and his team, as a guide.

Best of luck on figuring things out. Come back here as you need...

If you're capturing query metrics on SQL Server 2012 or greater, instead of using trace, I strongly recommend you use Extended Events. It's much more lightweight and easier to filter.

Oh, and, you're on 2014. The system_health extended events session captures deadlocks. You don't need 1204. It's just going to dirty up your logs.

I honestly hate trace flag discussions.

However, I'd suggest adding 2371 to the list.

Strong recommendation.

Don't use the ring buffer target. It's very attractive, but it leads to problems. Read this post by Jonathon Kehayias for details.

One immediate concern I would raise with whoever has asked you to back up a table instead of the database. How do you restore it? You need a plan for...

Target and Total Server Memory are frequently identical after the server has been running for a bit. SQL Server will consume the memory available and then hold on to it....

I'd monitor it using Extended Events (or if you're on 2008, Trace Events). You can capture the query. You won't see the data, but you can see the query.

Yeah, I agree with Drew. Rather than try to capture the SELECT statement, just capture the data from the data modification through the OUTPUT clause.