Fast ordered delete using a view

To perform a fast ordered delete, take a look at the article  Fast Ordered Delete provided by Kevin Stephenson of MySpace and Lubor Kollar, a member of the SQL Server Customer Advisory Team. What makes the article of particular interest is that the client is MySpace. It stands to reason then that the database in question here will be particularly large and provides a good test case for this proof of concept. The crux of the solution presented focuses on replacing a subquery within the where clause, with a view definition that identifies the records to be deleted .

Before:

delete from t1 where a in (select top (10000) a from t1 order by a);

After:

create view v1 as (select top (10000) * from t1 order by a)

delete from v1

You can see the difference and resulting simplification in the exeuction plans produced for these queries in the article Fast Ordered Delete.

This implementation lends itself well to batching delete operations, a technique that is used to limit the transaction log space used by a delete operation and to facilitate more frequent truncation of the transaction log.

Fast ordered delete using a derived table

The previous solution  focused on utilising a view in order to simplify the execution plan produced for the query. This was achieved by referencing the given table once, rather than twice which in turn reduces the amount of I/O required. Interestingly, the same goal can be achieved by using a derived table as explained by Simon Sabin in the article Delete Top X rows avoiding a table scan

Working with large database tables

Perhaps one further consideration that is worthy of being raised here is database table design. For example, if during the design process for a database system it becomes apparent that a significant number of delete operations will be required for a given table, it is then likely that the table in question would be a good candidate for SQL Server Partitioning and in particular Sliding Window Partitioning. Such an implementation would allow for the Switching in and out of partitions without adverse performance implications.

For further reading, consult the Microsoft Whitepaper: How to Implement an Automatic Sliding Window in a Partitioned Table on SQL Server 2005

Can’t Find the Answer Your Looking for?

Got a SQL Server question that you can’t find the answer to? Sounds like a great problem to have , let me know about it!

You may also be interested in…………..

• How much memory is each SQL Server database using?
• How to identify the most costly SQL Server queries using DMV’s
• The SQL Server Buffer Pool and Buffer Cache Hit Ratio
• How to become a SQL Server DBA

Have you ever come across a stored procedure that utilises parameters and performs like a dream the majority of the time but for some reason crawls along on some other occasions? Well the chances are that this is down to SQL Server Parameter Sniffing.

I was re-reading through the white paper Batch Compilation, Recompilation, and Plan Caching Issues in SQL Server 2005 again this week. It reminded me of the fact that Parameter Sniffing catches a lot of people out and so I wanted to share with you the details of how this issue can arise so that you may avoid it in your environments.

What is Parameter Sniffing?

“Parameter sniffing” refers to a process whereby SQL Server’s execution environment “sniffs” the current parameter values during compilation or recompilation, and passes it along to the query optimizer so that they can be used to generate potentially faster query execution plans. The word “current” refers to the parameter values present in the statement call that caused a compilation or a recompilation.

How does Parameter Sniffing work?

You can find an excellent article here by Omnibuzz providing an example walk-through of the issues of Parameter Sniffing.

Where can I find out more?

For an excellent discussion on Parameter Sniffing and other similar query tuning issues take a look at the Microsoft reference Batch Compilation, Recompilation, and Plan Caching Issues in SQL Server 2005.

I hope you find this information useful in both troubleshooting and more importantly, avoiding issues with SQL Server Parameter Sniffing.

One of my favourite series of articles regarding good T-SQL coding practices is by Jeff Moden over at SQLServerCentral.com. Jeff discusses how to avoid RBAR (pronounced “ree-bar” and is a “Modenism” for “Row-By-Agonizing-Row”) using his humorous narrative tones.

I highly recommend you take a look at this enjoyable read. Hidden RBAR: Triangular Joins