The Bit Bucket

I’ve ended up with a number of Microsoft figurines over the years. It all started with Nine Guy:

Then it went on to the whole Source Force team:

It was interesting to see how they evolved over the years. Here are the SQL Server ones:

SQL Server 2005 had a demure little lady that was all Red. She morphed into an orange version by SQL Server 2008 (shown in the header with me at TechEd USA) in 2008. Later she took on a Neo look from the Matrix. More recently, there was a guy, the Query Controller.

2026-06-17

When you’re dealing with real-time or high-volume event data, one of the first challenges is scale — there’s simply too much information to interpret at the individual event level. That’s where aggregations come in. Aggregations are the process of summarizing large numbers of rows into meaningful metrics that humans can easily interpret.

For example, if you’re collecting IoT sensor readings from thousands of devices, it doesn’t make sense to inspect each data point individually. Instead, you might calculate the average temperature per minute, the total number of readings received, or the maximum pressure recorded in the last hour. Those aggregated values turn a flood of raw data into something you can analyze and act on.

2026-06-16

I recently wrote about how SQL Server related tooling has been pushing us to use constraints like primary keys, check constraints, and unique constraints without naming them ourselves. But a similar issue applies to DEFAULT constraints.

With DEFAULT constraints, the issues are slightly different.

The first issue with them is the same as with the other constraints. They can cause havoc with deployment and schema-comparison tooling unless you find and use options to ignore any system-generated names.

2026-06-15

In KQL, time is one of the most important concepts — it’s central to how telemetry and log data are analyzed.

Most KQL datasets include a Timestamp column, and nearly every query begins by filtering to a specific time range.

You can do that using a where clause, such as:

| where Timestamp between (ago(1h) .. now())

This filters your events to just those that occurred within the last hour. It’s an efficient way to narrow down large datasets quickly.

2026-06-14

For many years, SQL Server related tooling has been pushing us to use constraints without naming them ourselves. But SQL Server requires these to have names so it generates names for them. These system-generated names aren’t very helpful.

What’s the issue with system-generated names?

The first issue with them is that they can cause havoc with deployment and schema-comparison tooling unless you find and use options to ignore any system-generated names.

2026-06-13

In KQL, projections are how you shape your dataset — deciding which columns to keep, how to name them, and even adding new ones on the fly.

The main operator for this is project. It lets you select only the columns you need, and at the same time, you can rename columns using aliases to make your results more meaningful or easier to read. For example:

Events
| project Time = Timestamp, User = UserId, Message

Here, the column Timestamp is renamed to Time, and UserId becomes User. This makes your results cleaner and easier to understand — especially when you’re building queries for dashboards or reports.

2026-06-12

When you visit websites, you may or may not have noticed the small icons that appear in the title bar areas. These are called Favicons. Here’s an example of one in Chrome:

In browsers, they appear in several places:

They are only a small visible aspect of your website but they greatly improve how professional the site looks in a browser. In some browsers, they also appear when you open a new page:

2026-06-11

When we start working with large volumes of data, one of the first and most important things we need to do is filter. Filtering is all about reducing noise — narrowing down the data that we really need so that we only keep the rows that are relevant to our analysis or our business needs.

In most systems, rows contain a mix of everything: normal activity, background data, edge cases, and sometimes even junk messages. If we tried to process or visualize all of it, our queries would slow down, and costs would rise, and the signal we care about would get buried in the noise. Filtering allows us to focus only on what matters.

2026-06-10

A question came up from a developer yesterday. He could see how to set a transaction isolation level but didn’t know how to determine the current transaction isolation level. That detail is available in the sys.dm_exec_sessions DMV.

Here’s an example:

SELECT COALESCE(CHOOSE(transaction_isolation_level,
                       'Read Uncommitted',
                       'Read Committed',
                       'Repeatable Read',
                       'Serializable',
                       'Snapshot'),
                'Unspecified') AS CurrentTransactionIsolationLevel
FROM sys.dm_exec_sessions  
WHERE session_id = @@SPID;

2026-06-09

Let’s look at how a basic KQL query is structured.

Every KQL query starts with a table — that’s your starting dataset, like Events, Logs, or Telemetry. From there, you build a pipeline of operations using the pipe (|) symbol, which passes the output of one operation into the next.

The most common first step is to filter the data using the where operator. It works just like a SQL WHERE clause but uses a more natural, functional syntax. For example:

2026-06-08