The Bit Bucket

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

KQL, or Kusto Query Language, is a read-only, declarative query language.

Unlike SQL, which is procedural and typically runs in relational systems, KQL is pipeline-based. Each operation feeds directly into the next using the pipe (|) operator. This makes it incredibly intuitive once you get used to it — you start with a dataset, apply filters, transformations, and aggregations step by step, building your query like a flow of operations.

2026-06-04

I saw a question on a SQL Server mailing list about how to determine the Windows groups for a given SQL Server login.

That’s actually easy for a sysadmin login, as they have IMPERSONATE permission for other logins/users.

Here is an example procedure:

USE tempdb;
GO

CREATE OR ALTER PROCEDURE dbo.GetGroupsForALogin
@LoginName sysname
AS
BEGIN
    EXECUTE AS Login = @LoginName;

    SELECT [name] AS GroupName,
           usage AS Usage
    FROM sys.login_token 
    WHERE [type] = N'WINDOWS GROUP';
END;
GO

When I executed this on one of my SQL Server 2025 systems this way:

2026-06-03

In an ideal world, every event in a data stream would arrive exactly when it was generated and in perfect chronological order. But in reality, streams are messy. Events can arrive late, out of sequence, or even replayed after retries. This is a normal characteristic of distributed systems — not a failure — and it’s something we need to design for in any real-time analytics pipeline.

There are several reasons why events might not arrive in order. Sometimes there’s network latency between devices and the ingestion point. Other times, devices might buffer data locally and send it in batches when a connection becomes available. In cloud or IoT scenarios, retries or transient service interruptions can also cause duplicates or delayed messages. So, when you’re analyzing a stream, the order of arrival isn’t always the same as the order of occurrence.

2026-06-02

I recently received a review copy of Extreme DAX: Take your Power BI and Fabric analytics skills to the next level by Michiel Rozema, Madzy Stikkelorum, and Henk Vlootman from my friends at PackT.

Authors

Michiel Rozema is a long-term IT industry veteran. He was the data insight lead at Microsoft Netherlands and launched Power BI in the country. Michiel works as a data analyst and architect for his company Qanto. He is a fellow Data Platform MVP.

2026-06-01