Following the recent release of SQL Server 2012 Service Pack 2 and SQL Server 2014 Cumulative Update #3, SQL Sentry's Aaron Bertrand (@AaronBertrand) takes a first look at a new performance enhancement and trace flag (2453) aimed at improving cardinality estimates for table variables and table-valued parameters.
Jonathan Kehayias (@SQLPoolBoy) of SQLskills.com evaluates the performance impact of query_post_execution_showplan and explains why you need to be very careful about using it in a production environment.
In an effort to encourage you to keep your SQL Server 2012 instances up to date, I wanted to highlight a slew of performance-related fixes that are mostly available only through Service Pack 1 or various Cumulative Update packages.
Recently, Microsoft pushed out Service Pack 1 for SQL Server 2012, and they quickly followed up with Cumulative Update 1 for Service Pack 1. The reason for this is that the service pack – due to longer development and regression testing cycles – did not contain any of the fixes from RTM Cumulative Updates 3 & 4. Since many people have waited – based on mostly speculative bias at this point – to even start testing SQL Server 2012 until Service Pack 1 was released, I thought it might be useful to cover a couple of the scenarios you might come across.
As you have most certainly heard elsewhere, SQL Server 2012 finally offers a version of Extended Events that is a viable alternative to SQL Trace, in terms of both better performance and event parity. There are other enhancements such as a usable UI in Management Studio – previously your only hope for this was Jonathan Kehayias' Extended Events Manager.
Medians require sorting. Sorting in SQL Server is typically a pretty expensive operation if there isn't a supporting index, and adding an index to support an operation which probably isn't requested that often may not be worthwhile. This post explores the performance characteristics of several solutions to the median problem.
I see a lot of advice out there that says something along the lines of, "Change your cursor to a set-based operation; that will make it faster." While that can often be the case, it's not always true. One use case I see where a cursor repeatedly outperforms the typical set-based approach is the calculation of running totals. This is because the set-based approach usually has to look at some portion of the underlying data more than one time, which can be an exponentially bad thing as the data gets larger; whereas a cursor – as painful as it might sound – can step through each row/value exactly once.