The archives network's donor-relationship data lives in an operational Azure SQL Database used by the development office, and analysts want that data reflected in OneLake as near-real-time, read-only Delta tables without the team building and maintaining a custom extraction pipeline. Which Fabric capability directly fits this need?
Select an answer to reveal the explanation.
Short Explanation
Think of mirroring like a live video feed from another building instead of someone walking over with a USB drive every few minutes: the picture updates on its own, continuously, with nobody manually running the errand. That's what mirroring gives you for the donor database, without a pipeline to maintain.
Full Explanation
Mirroring is a Fabric feature purpose-built for continuously replicating supported operational databases — including Azure SQL Database — into OneLake as near-real-time, read-only Delta tables, with the replication managed by the platform rather than by a custom-built pipeline. That matches both stated requirements: near-real-time freshness and no pipeline to build or maintain. A pipeline with a Copy Data activity on a five-minute schedule can approximate freshness, but it is still a pipeline the team has to build, monitor, and keep working, which is exactly the maintenance burden mirroring is meant to remove. A Dataflow Gen2 refreshed frequently faces the same issue — it's a maintained artifact with its own refresh schedule and failure modes, not a zero-pipeline continuous replication. A manual export-and-import process is neither near-real-time nor low-maintenance; it depends on someone remembering to run it and introduces long, unpredictable staleness windows. Before adopting mirroring here, confirm Azure SQL Database is on Fabric's list of supported mirroring sources, since not every database engine is eligible.