Press "Enter" to skip to content

Author: Kevin Feasel

SQL Server and January 2026 Patch Tuesday

Rebecca Lewis takes a look at a recent security vulnerability:

Microsoft’s January 2026 Patch Tuesday included a security fix for SQL Server: CVE-2026-20803, an elevation of privilege vulnerability with CVSS score 7.2 (Important).

The vulnerability is classified as CWE-306: Missing Authentication for Critical Function. An attacker who already has high-level privileges on the SQL Server instance could exploit this flaw to escalate further — gaining debugging privileges, dumping system memory, and potentially extracting sensitive data or credentials.

Read on for more information about the CVE, what it requires to exploit, and how you can patch SQL Server to prevent it from being an issue. It’s interesting that this only affects SQL Server 2022 and 2025.

Comments closed

Performance Testing Sequential Number Generation

Louis Davidson breaks out the stopwatch:

I have read so much lately about how bad it is to use a recursive CTE to do… well pretty much anything. It came up in a discussion about creating sequential number, and not in a positive sort of way.

I wrote about recursive CTEs when they were first added to SQL Server, and have been a fan for doing breadth-first searching of a hierarchy/graph, but never even thought to use one to generate a set of numbers. As I kept hearing how bad it this method was, so I figured, let’s see just how terrible it is. And of course, I needed something to compare to, so I decided to try all of the ways I could think of. So I will generate varying numbers of rows with the following methods:

Read on for the list of competitors and how they did.

Comments closed

Table Statistics and Planning Slowdowns

Andrei Lepikhov digs into a performance issue:

A query executes in just 2 milliseconds, yet its planning phase takes 500 ms. The database is reasonably sized, the query involves 9 tables, and the default_statistics_target is set to only 500. Where does this discrepancy come from?

This question was recently raised on the pgsql-performance mailing list, and the investigation revealed a somewhat surprising culprit: the column statistics stored in PostgreSQL’s pg_statistic table.

Read on for Andrei’s analysis and some interesting thoughts on possible avenues for improvement.

Comments closed

Setting up Azure SQL Mirroring to Microsoft Fabric

Olivier Van Steenlandt troubleshoots an issue:

When setting up database mirroring from Azure SQL to Microsoft Fabric for one of my demo databases, I ran into an issue while trying to connect to my Azure SQL database.

As you can see in the screenshot above, it seems that a setting on my logical SQL Server in Azure is misconfigured. Let’s resolve that in a couple of steps.

Click through for the screenshot, the specific error, and how Olivier was able to get things working.

Comments closed

Materialized Lake Views in Microsoft Fabric

Jon Lunn digs into a somewhat-new feature:

So first off, what are they? They are basically a table object that is based on a query. (Yes I know they are called ‘Views’… more on that later) So like a view, it is defined by a SQL query, but it doesn’t just sit over tables and runs that SQL when you query that view. What it does do is take the ‘View’ SQL query that defines the Materialised Lake Views, runs it and stores the query result data into a delta table. So when you query that view, you get the data from that object, and not the underlying tables. Neat! Save a bit on computing query time!

Read on to learn more about what they are, how they work, and when they can be useful.

Comments closed

T-SQL Tuesday 194 Round-Up

Louis Davidson has made a big mistake:

As I sit here, preparing to write my roundup post, I have not read anyone else’s post yet. I thought it would be good to introduce the idea first, recap to the other posts, then mine. I won’t share any detail of the mistake I shared, but I do want to mention something I included in my post. Types of mistakes. Mistakes of choice, and mistakes of accidents.

Read on for a nice round-up of a popular topic.

Comments closed

The Complexity of Cloud Security

Rebecca Lewis shares a tale of woe:

Cloud-based SQL Server security isn’t simpler. It’s different — and the learning curve is brutal if you grew up on-prem.

If you’ve spent years working Windows authentication, SQL logins, role memberships, and the occasional certificate, you may assume cloud security is more of that, just with a portal. Not. The SQL Server/Cloud permission models are layered differently, the terminology shifts depending on the platform, and the people who ‘own’ security are spread across teams that don’t always speak the same language.

Read on for an example of the kinds of challenges you can run into. Adding to that complexities around managed identities and authorization mechanisms and things can get very convoluted, even when the intent is to simplify matters.

1 Comment

Workspace-Level Surge Protection Controls in Microsoft Fabric

Pankaj Arora announces a new preview feature:

Until now, surge protection applied only at the capacity level—meaning all workspaces shared the same rules.

What’s new: workspace-level surge protection

We’re taking surge protection to the next level with workspace-level controls. This update gives you more granular management of compute usage across your organization.

Read on to see what this means for organizations using Microsoft Fabric.

Comments closed

Buffers in PostgreSQL

Radim Marek goes deep into buffers:

The work around RegreSQL led me to focus a lot on buffers. If you are a casual PostgreSQL user, you have probably heard about adjusting shared_buffers and followed the good old advice to set it to 1/4 of available RAM. But after we went a little bit too enthusiastic about them on a recent Postgres FM episode I’ve been asked what that’s all about.

Buffers are one of those topics that easily gets forgotten. And while they are a foundation block of PostgreSQL’s performance architecture, most of us treat them as a black box. This article is going to attempt to change that.

Read on to learn more about how PostgreSQL users buffers.

Comments closed