Press "Enter" to skip to content

Category: Mirroring

Lessons Learned from Replicating BigQuery to Microsoft Fabric

Teo Lachev shares some knowledge:

A recent engagement required replicating some DW tables from Google BigQuery to a Fabric Lakehouse. We considered the Fabric mirroring feature (back then in private preview, now publicly available) and learned some lessons along the way:

1. 400 Error during replication configuration – Caused by attempting to use a read-only GBQ dataset that is linked to another GBQ dataset but the link was broken.

Read on for additional tips, including a major one around permissions.

Leave a Comment

Fabric Mirroring for Azure SQL MI Now GA

Ajay Jagannathan announces a feature has gone to general availability:

Mirroring in Fabric is a powerful feature that allows you to replicate data from various data sources such as your Azure SQL Managed Instance to Fabric’s OneLake. This ensures that your data is always up-to-date and readily available for advanced analytics, AI, and data science without the need for complex ETL processes.

Jokes about Azure SQL Managed Instance aside, it’s good that these features are becoming generally available.

Leave a Comment

Microsoft Fabric Mirroring and Live Monitoring

Teo Lachev is waiting for a message:

A current project called for mirroring a Google BigQuery dataset to Fabric. This feature is currently in private preview so don’t try to find it. However, the tips I share here should be applicable to other available mirroring scenarios, such as mirroring from Azure SQL Database.

One of the GBQ tables was a transaction fact table with some 130 million rows. The issue was that the mirroring window would show this table as normally replicating table with Running green status, but we waited and waited and nothing was happening…

Read on to learn more and how Teo was able to get a better idea of how the initial sync progressed.

Comments closed

Mirroring in Microsoft Fabric

Swetha Mannepalli explains how mirroring works in Microsoft Fabric:

Data is complex. It’s often scattered across multiple systems, stored in various formats, locked in silos and changing all the time — making it difficult to harness its full potential. Bringing this data together to power AI and BI workloads typically requires time-consuming ETL processes, custom pipelines, and deep technical expertise. There’s no simple way to get started…until now. 

Click through for more details. And I get the complaint that the term “mirroring” has a different meaning in SQL Server, and that Fabric mirroring from a SQL Server instance doesn’t actually use the mirroring technology that has been deprecated since 2012 but still remains in the product because reasons. But in fairness, there are only so many synonyms people can use. Which means, three years from now, marketing will rename the feature to “replication.”

Comments closed

Azure SQL Mirroring in Microsoft Fabric Updates

Idris Motiwala announces a set of changes:

Attention data engineers, database developers, and data analysts! We’re pumped to reveal exciting upgrades to Mirroring for Azure SQL Database in Fabric today at the Fabric Conference in Las Vegas 2025. Since it became Generally Available, Mirroring for Azure SQL Database has been a game-changer, letting you replicate data seamlessly and integrate it within the Fabric environment. We’re talking near real-time data accessibility and some serious analytics power!

Click through to see what’s new, as well as what’s upcoming. This is specifically for Azure SQL DB and Azure SQL Managed Instance, versus SQL Server running as an Azure VM or on-premises (or some other cloud), so calibrate expectations accordingly.

Comments closed

Setting RCSI on a Database in an Availability Group

Haripriya Naidu makes a change:

I was working on modifying isolation level of database from Read Committed to Read Committed Snapshot(RCSI) and had to get exclusive access to the database. After letting the application team know about it and having stopped their processes, I tried to set the database to SINGLE_USER but it errored out.

It turns out that you cannot set a database to single user mode if it is in an availability group or part of database mirroring. Nonetheless, there is still a way to make this change. Read on to learn more.

Comments closed

Low-Downtime Migration Techniques from SQL Server 2017 to 2022

Yohei Kawajiri describes three techniques for performing a SQL Server migration:

It is possible to configure a SQL Server Always On availability group with a primary replica running on SQL Server 2017 and a secondary replica running on SQL Server 2022, but there are important considerations and limitations to keep in mind: 

  1.  Backward Compatibility: SQL Server supports having replicas on different versions, but the primary replica must be on an older version than or equal to the secondary replicas. Therefore, having SQL Server 2017 as the primary and SQL Server 2022 as the secondary is valid. 
  2.  Database Upgrade Path: When you decide to upgrade the primary replica to a newer version, you need to follow a specific upgrade path to ensure minimal downtime and data integrity. 

Building an availability group? Yeah, makes a lot of sense. Performing log shipping? Sure, I could see that working. Database mirroring? I did not expect to read that one, mostly because it’s been deprecated for a decade.

Comments closed

Mirroring Snowflake to Microsoft Fabric

Reza Rad hogs the photocopier:

Microsoft Fabric offers an end-to-end SaaS analytics solution; however, the world is using all kinds of data sources in its implementation. Mirroring is a new functionality in Fabric that allows customers to keep their data wherever they are, but then they can use Fabric analytics solutions with the same speed and performance as if their data were in Fabric. Best of all, this won’t cost extra. If you wonder what it is and how it works, read this article.

Click through for the video and article.

Comments closed

Mirroring Azure SQL DB into Microsoft Fabric

Dennes Torres holds up a mirror:

You need to read data from production to build a single source of truth. If you create pipelines reading directly from production, you will create additional load over the production environment. The mirror allows you to do much of the production reporting from the mirror, leaving the production environment to serve other users. Keep in mind, production report, but not analytics report.

Mirroring a production database to Fabric is one method to ensure the load over production will be as low as possible and the data will be transferred fabric to complete the transformations from this point.

Only this? What about avoiding pipeline creation? Not really, you still need to create pipelines, as I will explain ahead.

Click through for the demo and explanation. This is an important thing for people to note: mirroring doesn’t eliminate ELT. You still have the data lake process to work through, as your transactional system does not and should not look like your reporting system.

Comments closed