A Fine Slice Of SQL Server
Vlad Drumea comes up with a list:
This is my list of “main suspects” that make me instantly think a query is bad as soon as I see at least one of them.
Note, this is just based on the query text alone, seeing the execution plan is an instant confirmation.
Now, without further ado and in no specific order:
Click through for the list. There are some good items on it.
Leave a CommentReitse Eskens checks the logs:
As you’ve probably heard and read before, monitoring your Fabric environment as a whole is quite important. It really does help to know what’s going on.
Now, one thing I’ve learned over all these years is that report users do quite like their data to be as fresh and up to date as possible. And, when the data seems stale, they tend to ask questions.
Read on for some notes covering how to refresh a semantic model, when you might want to, how to automate it, and how to monitor the refresh process.
Leave a CommentRuben Van de Voorde announces a new update:
Since announcing the Tabular Editor CLI, we’ve been hard at work polishing the CLI and bashing the bugs we found, thanks to your help. We deeply appreciate all the input we received so far through GitHub, talking to you at events, comments on these blogs, and all other channels you engage with us (leave yours at the bottom of this page). Keep it coming!
We’re now at a point where we feel ready to share the updated version with you: version 0.6.0.
This is still in a limited public preview, so it’s free until the end of September. After that point, it becomes a paid product.
Leave a CommentRebecca Lewis answers a question:
This post is part of T-SQL Tuesday #200, hosted this month by Brent Ozar. The prompt: “When I’m looking at a query, I bet it’s bad if I see ____.”
Easy. I didn’t even have to think about it. When I open a stored procedure and see a function wrapped around a column in the WHERE clause, I groan. Out loud. Because more often than not, it means the predicate is non-SARGable, and non-SARGable means your indexes just became very expensive shelf decorations.
That is a pretty good answer, yes. Almost nothing good comes from wrapping columns with functions in the WHERE clause or as part of a join criterion.
Leave a CommentJames Serra takes us through the different security models in Microsoft Fabric:
The idea behind Fabric OneLake Security (which GA’d on April 2026) is to centralize data access controls at the data layer, rather than configuring security separately for every Fabric experience. You define security once, close to the data in OneLake, using roles that can control access at the folder, table/object, row, and column levels through object-level security (also called Table-level and folder-level security), row-level security (RLS), and column-level security (CLS). Those rules are then enforced by supported Fabric engines and access paths, such as Lakehouse, Spark notebooks, the SQL analytics endpoint in user identity mode, and Power BI Direct Lake semantic models. Downstream experiences that go through those governed paths, such as Power BI reports or Excel connected through the semantic model, inherit the same secured view of the data.
However, OneLake security is not the native security model for every data location in Fabric.
Read on to see which components use what security models, as well as some hints as to the vision for Microsoft Fabric’s ultimate security model.
Leave a CommentKevin Chant gives the low-down on Microsoft Fabric:
This post covers how you can spread your SQL Server wings with Microsoft Fabric in 2026. As part of a long-running series of posts about spreading your SQL Server wings with the Microsoft Intelligent Data Platform.
Just after Microsoft Fabric was publicly announced during Microsoft Build 2023, I published a post that covered spreading your SQL Server wings with Microsoft Fabric.
A lot has changed since then. Including Microsoft Fabric becoming generally available and the introduction of more workloads. Since Data Days is currently taking place, I decided to publish an updated version.
There’s a lot that has changed in the product, meaning that if your experience with it was how it looked in early 2024, it’s a different world now.
Leave a CommentJohn Cook follows Betteridge’s Law of Headlines:
In general, new information reduces your uncertainty regarding whatever you’re estimating. The posterior distribution becomes more concentrated as more data are collected.
That’s what happens “in general” but does it necessarily happen every time you get new data? Conceivably if you get surprising data, data that is very unlikely given your current prior, posterior uncertainty might increase.
Click through for an example, as well as a pair of good comments on the post.
Leave a CommentChris Webb diagnoses a case of passive voice:
A few months ago I wrote about a rare error – the “Maximum allowable memory allocation” error – that may occur when the physical machine, or node, that a semantic model is running on in the Power BI Service comes under memory pressure. Recently, someone I was working with who was doing some load testing showed me a related error:
The operation was canceled and the database was evicted to balance the CPU load on the node. Please try again later.
Read on to see what causes this.
Leave a CommentRuben Van de Voorde digs into data apps:
Fabric data apps are the most interesting thing to happen to data visualization in Power BI and Microsoft Fabric, ever. They provide limitless potential for how to visualize and interact with your data. However, they also indirectly provide a major benefit to your semantic models by allowing them to be simpler to build, use, and maintain.
In this article, we argue that data apps provide a reporting layer that is separate from the semantic layer, something that wasn’t true in Power BI due to tight coupling between reports and semantic models.
Click through to see where they fit vis-a-vis Power BI reports and semantic models.
Leave a CommentMartyn Jones sees dead records:
When a delete operation is executed, or when an update causes a page split, a marker is set in the page header, and each row is marked to show that the record is to be deleted; this is the process of creating ghost records. The concept is to improve performance as the data is not immediately removed, and, with row-level locking, it helps minimise blocking and supports efficient concurrency under typical isolation levels such as Read Committed and above. If a transaction is later rolled back, the cost of effectively restoring the row is considerably reduced as the data doesn’t need to be reinserted, only the marker removed. Later demos will show this in action.
This is the first part of a longer series on ghost records and ghost cleanup.
Leave a Comment