Press "Enter" to skip to content

Category: Warehousing

Fetching Query Plans in Fabric Data Warehouse

Louis Davidson shows a process:

So in this next entry in this series, I want to start to cover a topic that every nerdy SQL programmer is going to want to know. “How do I make a query faster?” If you have worked with relational databases, you know the simple answer is to… check the estimated query plan, run the query and look at the actual plan, and in many cases to be completely honest, add indexes.

Click through to see how closely your current SQL Server skills translate in this instance. The specifics of query tuning and table design in the Fabric Data Warehouse will differ a bit from on-premises SQL Server, but at this level, it’s quite similar.

Leave a Comment

Shortcuts to Iceberg Tables in Microsoft Fabric

Teo Lachev makes a connection:

Snowflake is an increasingly popular option for data warehousing. One nice Snowflake feature is the ability to configure a table to save its data in Iceberg file format in the Snowflake own managed storage or external storage, including S3, GCS, ADLS Gen 2, and OneLake. As I wrote in the post “Give Me Your Data!”, Fabric supports shortcuts to Iceberg tables, in which case the data is not copied but exposed as a Parquet Delta table in a Fabric lakehouse. This could be useful when building Fabric-centric solutions on top of Snowflake without moving the data.

Iceberg isn’t just a Snowflake thing, though this is certainly helpful if you do have both Snowflake and Fabric.

Leave a Comment

Setting Fabric Connection Properties with the ODBC Driver

Ryan Adams digs into configuration settings:

Some SQL Server ingestion scenarios depend on connection-string properties that the built-in SQL Server connector in Data Factory for Microsoft Fabric doesn’t expose. If you need to route reads to an Availability Group secondary, connect reliably across a multi-subnet listener, or read columns protected by Always Encrypted, you’ve probably hit that wall. This post shows a supported way around it: use the ODBC connector together with an ODBC data source name (DSN) configured on an on-premises data gateway (OPDG). The example in this post uses Always Encrypted in a Copy job.

Click through to see some of the things you can set. These are standard SQL Server properties, so they can also work with normal SQL Server installations that are making use of Availability Groups and Always Encrypted.

Leave a Comment

Schema Locks and Time Travel in Fabric Data Warehouse

Louis Davidson continues a comparative analysis:

When reading that title, you probably want to get to concept of time travel first, because if you could really do that, you wouldn’t have any more backup and recovery problems. The time travel I will cover is about getting to past versions of data in your data warehouse tables. This is done in a similar way to what you can do with temporal tables in SQL Server, but also VERY different.

The schema locks section is a wee bit of a follow on to Part 4 where I covered isolation where I showed how updating data was handled concurrently. In this post I wanted to briefly finish that conversation and note how it works when you have schema locks.

Most of this behavior is similar to what we have in SQL Server on-premises, though time travel does have a couple of nuances to it versus the box product.

Leave a Comment

Implementing SCD Type 2 in Microsoft Fabric

Nikola Ilic reminds us that the Kimball model is alive and well:

Slowly Changing Dimensions (SCD) are one of the fundamental concepts in dimensional modeling. If you are not sure what dimensional modeling is, I suggest you first check the series of articles I wrote on data modeling some time ago.

And, when it comes to SCD in particular, SCD Type 2 is rightly considered “the queen” of the SCDs for analytical workloads. Without going into details (since the main goal of this article is to show you HOW to implement the SCD Type 2 in Microsoft Fabric), I’ll just briefly introduce the general concept behind the SCD Type 2.

Click through for a primer and examples in the warehouse and lakehouse.

Leave a Comment

Atomicity and Isolation in Fabric Data Warehouse

Louis Davidson receives a surprise:

Ironically, today’s topic is kind of the opposite. I expected things to be far different in Fabric, but it isn’t really that different, at least not in behavior, except when it is. Since this system is Parquet file based, I didn’t think there would be locking, blocking, etc. I sort of expected it would be sort of locked down when writing data, maybe just single threaded per file, but highly concurrent when reading. Reads would most likely work like time travel and read previous data where it existed. And transactions? Would there be transactions? I guessed not before I got started with it.

Was I wrong?

Read on for the answer. The concurrency model isn’t exactly the same as SQL Server’s, but it’s not that far off.

Comments closed

Dynamically Changing Fabric Data Warehouse SQL Pools

Gilbert Quevauvilliers saves some money:

After reading about the new SQL Pools feature for Warehouses in Fabric, I had an idea, if I could change the SQL Pool configuration based on the expected query load, I could then consume less capacity and have better performance.

https://learn.microsoft.com/en-us/fabric/data-warehouse/custom-sql-pools

Here is an Example I thought of below.

  • When the ETL load is running optimize the SQL pool for writing as typically data is being inserted.
  • After the ETL load and for the rest of the day, almost all queries are read by the Warehouse, so change the SQL pool to be read optimized.

Click through for a Python notebook that does this.

Comments closed

INFORMATION_SCHEMA and the Fabric Warehouse

Louis Davidson bangs his head against a wall:

When we decided to use T-SQL and a Fabric Data Warehouse for our ETL, I started thinking about generating the code with the metadata in the system catalog views or the INFORMATION_SCHEMA. Having done this sort of thing before in SQL Server over the years, it seemed really straightforward. And it kind of is, until it isn’t.

In this blog I want to show you a few ways you need to understand how working with metadata and temp tables varies (sometimes wildly) from the comfortable SQL Server environment and language you know very well, and give tips on how to get around these differences.

Click through for some of the fun you can have with a distributed SQL Server-like product.

Comments closed

Datatypes and Constraints in Microsoft Fabric Data Warehouses

Louis Davidson starts digging in:

There are three major “engines” in Fabric that I have seen that use T-SQL. There is the SQL Azure Fabric engine, the Lakehouse, and the Data Warehouse. Having this capability to manipulate data is wonderful, but there are some things you need to understand before you start writing code (unless you want to learn them the hard way like I have. I also will not profess to have found all of these differences. Changing my mindset when using these engines was the subject of this editorial

Read on for some inconsistency.

Comments closed

Checking Table Sizes in Microsoft Fabric Warehouses

Nikola Ilic wants to know how big that warehouse is:

If you’ve tried to check how much storage your Fabric warehouse tables consume, you’ve probably discovered that the usual SQL Server approaches don’t work. This post explains why, what else doesn’t work, and the one approach that does (and that I can use as a reference going forward, instead of wasting time and tokens asking LLMs).

Click through for the problem description and the answer. I completely agree with Nikola’s conclusion that it’s harder than it should be.

Comments closed