Paul Randal of SQLskills continues his series on maintaining happy and healthy transaction logs in SQL Server, this time focusing on configuration issues that can lead to less than optimal performance.
The Halloween Problem has a number of important consequences for SQL Server execution plans. In this final part of the series, we look at some of the tricks the optimizer uses to avoid adding an Eager Table Spool to every update query that might encounter the Halloween Problem.
The MERGE statement (introduced in SQL Server 2008) allows us to perform a mixture of INSERT, UPDATE, and DELETE operations using a single declarative statement. The Halloween Protection issues for MERGE are, logically enough, mostly a combination of the requirements for the individual operations performed, but there are some important differences and a couple of optimizations that apply only to MERGE.
Much has been written over the years about understanding and optimizing SELECT queries, but rather less about data modification. This series of posts looks at an issue that is specific to INSERT, UPDATE, DELETE and MERGE queries – the Halloween Problem.
Here is some information about an important MERGE "wrong results" bug, involving indexed views, that could be affecting the accuracy of your queries right now, and what options you have for working around the problem.
In my previous post on streamlining the operations of the transaction log, I discussed two of the most common causes of extra log records being generated: dead weight from unused nonclustered indexes and page split operations (that cause index fragmentation). Assuming you’ve read that post, I mentioned that there are more subtle problems that can be detrimental to transaction log performance, and I’m going to cover these here.
Earlier in this series (Part 1 | Part 2) we talked about generating a series of numbers using various techniques. While interesting, and useful in some scenarios, a more practical application is to generate a series of contiguous dates; for example, a report that requires showing all the days of a month, even if some days had no transactions.
In my previous post, I talked about ways to generate a sequence of contiguous numbers from 1 to 1,000. Now I'd like to talk about the next levels of scale: generating sets of 50,000 and 1,000,000 numbers.
There are many use cases for generating a sequence of values in SQL Server. I'm not talking about a persisted IDENTITY column (or the new SEQUENCE in SQL Server 2012), but rather a transient set to be used only for the lifetime of a query. Or even the simplest cases – such as just appending a row number to each row in a resultset – which might involve adding a ROW_NUMBER() function to the query (or, better yet, in the presentation tier, which has to loop through the results row-by-row anyway).