Enable Ownership Change / Take‑Over for Mirrored Database Items in Fabric
Mirrored DBs do not support ownership transfer today. This becomes an issue when someone leaves the company. And the user tied to the ownership is beeing disabled. That means you need to recreate the whole mirroring database and recreate all shortcuts, jobs pipelines etc etc.. Alot of work. The Take‑Over functionality exists for other Fabric items but excludes mirrored DBs. This is a critical operational need for enterprise workloads. Please consider developing this functionality.📉 How Would You Investigate a 20% Drop in Revenue?
A data analyst shouldn’t stop at identifying what happened. The real questions are: Where did the decline occur? → Why did it happen? → What caused it? → What should we do next? By analyzing regions, products, customers, time periods, and key business metrics, raw data can reveal the root cause behind the numbers. Good data analysis turns numbers into decisions. 📊 #DataAnalysis #BusinessIntelligence #PowerBI #MicrosoftFabric #DataAnalytics
Can we support Workspace ID authentication when using a gateway connection?
Currently, Workspace ID authentication is only available for cloud connections. We would like to request support for Workspace ID authentication when using gateway connections as well. <document :Authenticate with workspace identity> ---- ・You can create connections with workspace-identity-based authentication in the Manage Gateways and Connections experience for a cloud connection. ・Workspace-Identity-based authentication is currently not supported for gateway connections. ----
Improve Oracle Mirroring Health Monitoring and Data Validation Visibility in Microsoft Fabric
Problem Statement The current Oracle Mirroring monitoring experience in Microsoft Fabric primarily focuses on replication status and operational state. While tables may display a status such as "Running", users have limited visibility into whether replication is actively processing changes, whether replication has stalled, or whether mirrored data remains synchronized with the source system. Users Impact Customers face several operational challenges: A table may continue to show a "Running" status despite concerns that replication is no longer progressing. It can be difficult to distinguish between: No source-side changes occurring. Replication actively processing changes. Replication being stalled or unhealthy. There is no built-in source-versus-target validation capability. Customers must build their own custom monitoring solutions to validate synchronization health. Data discrepancies may remain undetected until reports or analytics results are questioned by end users. Proposed Enhancements 1. Mirroring Health Dashboard Extend the monitoring experience to include: Replication health status Last successful change processed timestamp Last successful CDC transaction processed Replication activity trends Mirroring latency indicators Synchronization confidence indicators 2. Source vs Target Validation Metrics Provide optional validation metrics such as: Source row count Mirrored row count Row count variance Validation status Validation timestamp This would allow customers to quickly assess synchronization health without implementing separate tooling. 3. Replication Stall Detection Introduce proactive detection of scenarios where: Tables remain in a Running state. No data has been processed for an unexpected duration. Source activity exists but replicated activity is not progressing. Provide warning indicators and configurable alerts. 4. Enhanced Alerting Allow customers to create alerts for: Excessive replication latency Replication inactivity Validation failures Synchronization drift exceeding configured thresholds Repeated replication retries Replication health degradation
Fabric Copy Jobs desperately need basic editability after creation.
Requiring users to recreate an entire Copy Job just to change something as fundamental as the source connection or connection URL is unnecessarily restrictive and creates significant maintenance overhead. A Copy Job should allow users to: Change the source connection Change the destination connection Edit connection details Repoint a job to a replacement connection Preserve existing mappings, scheduling, and other configuration when changing connections Having to rebuild a working job because one connection property needs to change makes Copy Jobs much less useful for production data workflows. Please add the ability to edit or replace connections on an existing Copy Job.Support Clustered Columnstore Tables with Nonclustered Primary Keys in Fabric Mirroring
Microsoft Fabric Mirroring should support source tables that use a Clustered Columnstore Index (CCI) when the table has a valid nonclustered primary key that can be used to uniquely identify rows. Today, tables containing a clustered columnstore index cannot be mirrored into Fabric. This creates a significant limitation for data warehouse and analytical SQL workloads because clustered columnstore indexes are commonly used for large fact tables and other high-volume analytical tables where compression and scan performance are important. Why this matters Clustered columnstore indexes are a standard physical design choice for large SQL Server and Azure SQL Database analytical tables. Customers should not have to choose between: Efficient columnstore storage and query performance in the operational SQL platform, or Near-real-time replication of the table into Microsoft Fabric and OneLake. Removing a CCI solely to enable Fabric Mirroring can significantly increase storage requirements and negatively affect existing analytical / HTAP workloads. It can also force customers to create duplicate rowstore tables purely for replication purposes. Desired outcome A table should be eligible for Fabric Mirroring when it has: A clustered columnstore index for physical storage. A valid nonclustered primary key or other supported unique key. Supported column data types. No other unsupported Mirroring features. Supporting this pattern would make Fabric Supporting this pattern would make Fabric Mirroring much more practical for existing enterprise data warehouses and large analytical SQL workloads without requiring customers to redesign otherwise well-optimized source tables.Support Views in Microsoft Fabric Mirroring for Azure SQL Database and SQL Server
Microsoft Fabric Mirroring should support database views as mirrored objects, specifically for Azure SQL Database and SQL Server sources. Today, Fabric Mirroring primarily operates against physical tables. Many production database environments, however, intentionally expose data through views rather than granting downstream consumers direct access to base tables. Views are commonly used to: Encapsulate business logic and transformations. Provide a stable abstraction layer over underlying schemas. Limit access to sensitive columns or rows. Simplify complex joins for downstream consumers. Maintain compatibility when underlying table structures change. Expose curated datasets specifically intended for analytics. Requiring Fabric Mirroring to access the underlying tables can bypass this abstraction and security layer and may require organizations to redesign existing databases solely to support Fabric ingestion. Requested capability Add support for selecting and mirroring views from: Azure SQL Database SQL Server, including supported on-premises and Azure-hosted SQL Server scenarios Views should appear alongside tables when configuring mirrored objects. Fabric should materialize the result of the view into OneLake so that downstream Fabric workloads can consume it using the same Delta/OneLake experience as mirrored tables. Desired behavior Ideally, the implementation would: Allow views to be selected individually during Mirroring configuration. Materialize each selected view as a queryable object in OneLake. Refresh view data incrementally where technically possible. Support scheduled or periodic materialization when true CDC cannot be derived from the view. Surface refresh status, failures, and lineage through the Fabric Mirroring experience. Preserve the existing source database security model where practical. Clearly identify mirrored views separately from directly mirrored tables in metadata and monitoring. Why this matters Azure SQL Database and SQL Server are widely used as operational systems where views represent the supported integration contract for downstream applications and analytics platforms. Supporting views would allow organizations to adopt Fabric Mirroring without: Exposing internal base tables. Duplicating view logic in Fabric. Building separate Data Factory or pipeline-based extraction processes. Creating additional staging tables solely to make data available to Mirroring. This would make Mirroring substantially easier to adopt in existing enterprise SQL Server and Azure SQL Database environments while preserving established data architecture, governance, and security patterns. Please extend Fabric Mirroring view support to Azure SQL Database and SQL Server as priority source systems.Support User-Defined Data Types (UDTs) in SQL Server Mirroring for Microsoft Fabric
Description Currently, SQL Server mirroring in Microsoft Fabric does not support User-Defined Data Types (UDTs). This limitation blocks ingestion and mirroring scenarios for databases that rely on UDTs, even when those UDTs are simple aliases of fully supported native SQL Server data types. Business Impact We are working with a third-party vendor database where: The schema is not under our control UDTs are used extensively throughout the model These UDTs are aliases of standard SQL Server data types (e.g., VARCHAR, INT, etc.) Because of this limitation, we are unable to leverage Fabric mirroring for this data source without introducing complex and potentially fragile workarounds (e.g., schema replication, type conversion layers, or ETL pipelines). Rationale Under the hood, SQL Server alias UDTs map directly to base system types. From a data movement and storage perspective, these should be fully compatible with existing Fabric mirroring capabilities. Blocking on UDTs: Creates unnecessary friction for onboarding common enterprise systems Prevents adoption in scenarios involving vendor-managed schemas Requested Enhancement Enable support for User-Defined Data Types (UDTs) in SQL Server mirroring by: Automatically resolving alias UDTs to their underlying base data types during ingestion/mirroring or Providing a configuration option to map UDTs to their base types Expected Outcome Seamless mirroring of SQL Server databases that use alias UDTs Elimination of unnecessary preprocessing or schema transformation steps Broader adoption of Fabric mirroring in enterprise environments with vendor-controlled schemas Additional Notes This request specifically targets alias UDTs, not complex CLR-based types.
