The Bit Bucket

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

I had a lot of good feedback on my recent post about how to query group membership for a given login.

One tricky additional question was about how you could let a specfic user be able to find the group membership for another login, without the user being a sysadmin to run the code.

Now doing that is a bit trickier but can be done by creating a certificate, a login from the certificate, then assigning permissions to that login, and finally applying a digital signature to the procedure using the certificate.

2026-06-07

It’s time to look at what makes KQL different from traditional query languages.

At its foundation, KQL works with tables, rows, and columns, just like SQL. The structure feels familiar, but the query model is quite different.

KQL queries are built from operators — like where, summarize, project, and extend — and these are chained together using the pipe (|) symbol. Each operator takes the output of the previous one and transforms it further. It’s like building a data pipeline, one step at a time. This makes it incredibly readable and modular — you can easily add, remove, or rearrange steps without rewriting the whole query.

2026-06-06

BACKUP TO URL was introduced as an add-on in Cumulative Update 2 for SQL Server 2012 Service Pack 1 and as a built-in feature for SQL Server 2014. I’ve talked about it in previous blog posts.

We have been using this in a variety of ways from on-premises systems:

For example, it is an easy way to distribute a backup of a database to a large number of systems. Imagine you have a chain of retail stores that needs product and other reference information updated regularly. You can keep this data in a separate database at the head office, back it up to an Azure Storage account, and have each store download it separately.  This has major bandwidth and reliability improvements over other solutions such as having each store maintain a VPN connection to the head office.

2026-06-05