While SQL Server’s plan cache generally is self-maintaining, poor application coding practices can cause the plan cache to become full of query plans that have only ever been used a single time and that are unlikely to ever be reused. We call this plan cache pollution.
The most common cause of these issues are programming libraries that send multiple variations of a single query. For example, imagine I have a query like:
2026-03-05
I always say that one of the things that I love about consulting or mentoring work is that I see things (mostly code) that I would have never have thought of.
Sometimes, it’s good information where I learn a new technique that I hadn’t considered. But most times, it’s just something weird that a client has done.
A good example of this was a site where every table had a GUID name. Yes, I’m talking about tables with names like:
2026-03-01
Recently, I saw a subtle coding issue related to the UNION operator. With SQL Server, the UNION operator combines two rowsets into a single rowset. If UNION ALL is used then all rows are returned. With just UNION without the ALL, only distinct rows are returned. All good so far.
One of the most common performance issues that I come across is where people have just used UNION where they should have used UNION ALL. That extra distinct operation is often not needed, yet often very expensive.
2026-02-27
Version 27 of our free SDU Tools for developers and DBAs is now released and winging their way out to our SDU Insiders.
You can find details on the tools here .
If you haven’t been using SDU Tools yet, I’d suggest downloading them and taking a look. At the very least, it can help when you’re trying to work out how to code something in T-SQL.
Along with the normal updates to SQL Server versions and builds, we’ve added the following new tools:
2026-02-19
Most people seem to be unaware that a CREATE SCHEMA statement can also include other DDL or DCL within it.
I’ve never been very keen on the option to add additional clauses in the CREATE SCHEMA statement as I’ve seen lots of issues when scripts are executed manually. You get a different outcome, depending upon how you execute it. For example, if you run statements in this script:
CREATE SCHEMA SomeSchema AUTHORIZATION Someone
CREATE TABLE Blah (Some table definition);
Where does the table Blah get created? Well, it depends.
2026-02-15
I had a discussion with a friend the other day who wouldn’t believe me that T-SQL allowed an UPDATE operation to be executed against a function in some situations. I must admit that when I first heard about it, it did my head in a bit as well, at least based on all I thought I knew about programming languages in general.
You can only perform an UPDATE against a table-valued function in T-SQL when the function was declared as an inline TVF. It still feels to me like it shouldn’t ever be permitted, but if you want to try it, here’s an example:
2026-02-13
It was great to catch up with Ben Weissman today and to have him on a SQL Down Under podcast.
Ben is a fellow Data Platform MVP.
Ben focusses on datawarehousing and analytics, still with a lot of on premises work but of course also Fabric / Azure work.
He has long experience with SQL Server, having started with SQL Server 6.5.
Ben says he loves to travel and loves food. He’s an author of books and video courses, and the organizer of data related events like Data Grillen, New Stars of Data, SQL Konferenz, and Data Saturday in both Vienna and Germany and other locations.
2026-02-11
Encryption in SQL Server is often discussed as a checklist item:
What gets discussed far less often is how these features behave in real systems, what problems they actually solve, and what trade-offs they introduce.
This post looks at Transparent Data Encryption (TDE) and Always Encrypted from a practical standpoint: what each one protects, what it doesn’t, and how to decide which one belongs in your design.
2026-02-01
One of SQL Server’s greatest strengths is its ability to execute queries in parallel. When parallelism is available, the engine can divide work across multiple CPU cores and dramatically reduce query duration for large or complex workloads.
Yet in real systems, it’s surprisingly common to find queries that could run in parallel but don’t. The reason is often not hardware, configuration, or cost threshold settings — but query anti-patterns that quietly force the optimizer into a serial plan.
2026-01-26
This is the thirteenth tale in a series of stories about data. I hope you enjoy the series.
Today’s tale relates to a SQL Server system that had wonderful hardware, yet was unbelievably slow. Let’s discuss what happened.
I had a call from the Microsoft office in Brisbane, Queensland, asking if I had time to look at a problem at a customer site. Both they, and the customer, had thrown considerable resources at trying to resolve a performance problem, but frustratingly, it persisted.
2026-01-24