The Bit Bucket

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

One of the more frustrating classes of SQL Server application failures is also one of the most avoidable: collation conflicts involving tempdb.

Background

I see these issues all the time. Developers create applications that require specific collations at the server level, because they don’t handle temporary tables (and by extension) tempdb well.

All this can be avoided, and you can easily build applications that will work with temporary tables, without worrying about the server (and tempdb) collation.

2026-01-26

Once events have been ingested, the next step is processing. This is where we take the raw firehose of events and turn it into something meaningful and usable.

NOTE: We’re not talking about storing the events in a database, and then querying them. We can do that, but here we’re talking about transforming the events in-flight. It’s similar to what we could do with Azure Stream Analytics. I like the description that says that instead of throwing a query at the data, you’re throwing the data at a query.

2026-01-25

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.

Some background information

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

Ingestion is the very first step in any real-time architecture: getting events from wherever they originate and bringing them into where they can be processed, analyzed, and acted on.

Events typically start their lives in all kinds of different systems. They might come from Kafka topics in an enterprise environment, AMQP brokers in messaging-based systems, or from Azure-native services like Event Hubs or IoT Hub, which are especially common in cloud and IoT scenarios. Ingestion is what connects those sources into Fabric. Without it, you don’t have anything to work with.

2026-01-23

When government funding is tight, it gets harder and harder to get grants to perform fundamental research. The government always wants to see outcomes, and this means that the grants committees need to show outcomes. In turn, this often leads to research funding bodies doing one of three things:

• Only funding research that’s nearly complete
• Only funding well-known researchers with a track record of outcomes
• Only funding research in areas that are already showing promise

Now while at first glance, that might sound a reasonable way to proceed, it’s not.

2026-01-22

Once we understand what an event is, the next concept is the stream. A stream is simply a continuous flow of events over time. Instead of looking at events one by one in isolation, a stream is what you get when you treat them as a live feed coming from a source.

For example, imagine an IoT scenario. Each sensor reading from a device is an event. But when you look at all those readings flowing in second by second, that becomes a stream of telemetry. In a financial system, every transaction is an event — but all transactions flowing in from your payment gateway form a transaction stream.

2026-01-21

This is a post in the SQL Interview series. These aren’t trick or gotcha questions, they’re just questions designed to scope out a candidate’s knowledge around SQL Server and Azure SQL Database.

Section: Administration Level: Advanced

Question:

A database backup was started at 12:00 PM. It completed at 2:00 PM.

When the backup is restored, at what time point will the restored data be?

• 12:00 PM
• 2:00 PM
• Somewhere between 12:00 PM and 2:00 PM

Answer:

2026-01-20

In real-time intelligence, everything starts with the concept of an event. An event is the most fundamental unit of real-time data — it’s simply a record that something happened.

That something could be almost anything, depending on your business. In finance, an event might be a stock trade or a payment transaction. In a web application, it might be a customer clicking a button, logging in, or abandoning a shopping cart. In IoT, it could be a sensor reading like temperature, vibration, or GPS coordinates. Even a server log entry or an error message can be considered an event.

2026-01-19

This is a post in the SQL Interview series. These aren’t trick or gotcha questions, they’re just questions designed to scope out a candidate’s knowledge around SQL Server and Azure SQL Database.

Section: Development Level: Medium

Question:

You have tables that have both constraints and triggers. You need to explain the order of execution for these. Which execution order (from first to last), are used for:

• Check constraints
• After triggers
• Instead of triggers

Answer:

2026-01-18