ICYMI: Troubleshooting CPU, Logging Myths, Missing Indexes, and Query Tuning Examples

Great Articles at SQLPerformance.com

There are so many good articles from SQLPerformance.com this ICYMI article that it’s hard to know which are best to highlight in the limited space.

So, I’ll be arbitrary and simply choose a few of my favorite entries as well look back:

Troubleshooting SQL Server CPU Performance Issues

This outstanding article from Joe Sack (b | t) of SQLSkills steps you through a methodical and insightful series of DMVs and queries that can pinpoint CPU issues on your SQL Server instances.

Don’t just blindly create those “missing” indexes!

Aaron Bertrand (b | t) discusses ways to get better and more balanced information used in decisions about creating new indexes than offered as suggestions by native SQL Server tools.

The Myth that DROP and TRUNCATE TABLE are Non-Logged

Paul Randal (b |t) at SQLSkills.com refutes the age-old myth that TRUNCATE TABLE and DROP are not logged operations. I love the full T-SQL reproduction of the issue so that you can see the internals in action.

Query Tuning Insight at Answers.SQLPerformance.com

More great query tuning tips and techniques are coming in at http://answers.SQLPerformance.com every week. Get involved! Start uploading your own difficult SQL statements, read the clever solutions to other query tuning challenges, and provide your own feedback. I always learn from Paul White (b|t), when I read his solutions to tough query turning problems. Here are a couple of my favorites:

 

 

Why doesn’t Query optimizer eliminate unneeded left join in view with Pivot?

Microsoft MVP Michael Swart (b | t) and Paul White discuss a query which delivers a bad plan and, in the process, go into a deep dive about how and at what stages the SQL Server query engine might simplify a query execution plan by removing unnecessary joins.

I want to optimize this query execution to improve its duration

Paul White dives into an interesting situation where a normal-seeming query causes intermediate work sets to spool to physical disk, thereby causing the query to run much too long.

How does SS determine JOIN operator row estimates?

Once again, Paul White teaches me new things.  This time he shows how to better understand and fix JOIN cardinality estimates.

 Let me know what you think! Thanks,

-Kev

-Follow me on Twitter!
-Google Author

Speak Your Mind

*

This site uses Akismet to reduce spam. Learn how your comment data is processed.