mirroring
34 TopicsMirroring SQL Endpoint Capacity Usage
Hi All, I've been working extensively with the Open Mirroring Database item in Microsoft Fabric, but I'm still trying to fully understand how its capacity (CU) consumption is calculated. From my understanding, the internal operations include components such as: OneLake Write via Redirect OneLake Iterative Read via Proxy OneLake Read via Redirect OneLake Read via Proxy OneLake Write via Proxy OneLake Other Operations My assumption is that these workloads account for activities such as data ingestion, CSV-to-Parquet conversion, data maintenance, vacuum operations, and other background processing required to keep the mirrored database operational. What I do not understand is the Warehouse SQL Endpoint Query Usage metric. On 11 August, this metric increased dramatically in our environment and has remained significantly elevated ever since. For one particular Open Mirroring Database item, usage increased from approximately 7K CU to 34K CU, and I am trying to determine what contributes to this workload and why it changed so suddenly. Before: Screenshot After: Screenshot Another observation is related to the Run By filter in the Capacity Metrics App. Prior to 10 August, I was able to filter consumption by individual user identities and clearly distinguish activity generated by specific users from activity generated by the system. However, from around 10/11 August, all user-generated activity appears to be grouped under a generic "User" identity, and individual users can no longer be distinguished or filtered. Before 10 August: Screenshot showing identifiable users After 10 August: Screenshot showing only "User" I don't understand what this new User identity represents. Is it an aggregation of all user-generated activity, a new classification introduced by the metering changes, or something else entirely? My current theory is that both the increase in Warehouse SQL Endpoint Query Usage and the change in the Run By filter may be related to the recent Fabric capacity metering changes, but I have not been able to find any documentation that clearly explains this behavior. Can anyone provide insight into the following? What specifically contributes to Warehouse SQL Endpoint Query Usage for an Open Mirroring Database? Do any of the internal mirroring processes execute through the SQL Endpoint and therefore appear under this metric? Did the recent Fabric metering changes alter how these operations are classified or billed? What exactly does the "User" identity represent in the Run By filter? Why did individual user identities disappear after 10 August and become a generic "User" value? Is the new User Identity dimension connected to the recent metering changes? Has the attribution model for user-generated workloads changed, resulting in individual users being grouped into a single category? Any clarification would be greatly appreciated, as these changes make it difficult to understand capacity consumption patterns and compare usage before and after 10 August. Thanks!12Views0likes0CommentsLive Community Session This Saturday: Unlock Microsoft Fabric’s Latest Feature
Live Community Session This Saturday: Unlock Microsoft Fabric’s Latest Feature – Mirroring! Join us tfor a power-packed live online session where we deep dive into Mirroring, one of the most exciting new features in Microsoft Fabric! Date: Saturday, May 18th Time: 11:00 AM – 12:00 PM IST Location: Online (Link will be shared upon registration) What You’ll Learn: What is Mirroring? – Understand the fundamentals and why it's a game changer. Mirroring vs. ETL – Learn when to use mirroring instead of traditional ETL. Compatible Databases – Find out what can be mirrored into MS Fabric. Live Demo – Mirror Azure SQL into Fabric step-by-step. Live Demo – Mirror On-Prem SQL Server into Fabric using a practical workaround. Open Mirroring – Explained & Demo – A special segment with Shashank Chhoker on Open Mirroring and its use cases. Presented by: Jitendra Sharma, Senior Technical Architect (15+ years of experience) Shashank Chhoker, Data Scientist, Orange Data Tech Moderated by: Samanvay Gupta, Community Advocate If you're a data engineer, architect, or Fabric enthusiast—this session is not to be missed!Sharepoint list mirroring
Hey, As I set up the basic SharePoint list, mirroring most of the data comes through without a problem. The issue is the fields categorized as User/Group type. (for example: Modified by / Created by fields in SharePoint lists) They don't seem to return the values, as they are nested data structures that mirroring just skips instead of giving the option to flatten them.Solved1.7KViews1like3CommentsMirror replication Premium extremely high consumption issue
Dear Community, We have switched on the CDF opportunity on 1-2 Mirrored database. We have noticed 30% minutes later we are almost knocked out the F32 license fully. We have on it extremnely small data. 10-20K records. Even the size is small also. Just rising to the sky without no reason. On the dev we have 20 table with 3K records....2.7KViews0likes14CommentsMirrored SharePoint List (Preview) - “Failed to get document libraries” Error 404
Hello everyone, I’m exploring the Mirrored SharePoint Online List (preview). I ran a test with a small list and it has been replicating changes correctly. However, I keep seeing the error 'led to get document libraries. Request failed with status code 404, x-ms-root-activity-id: …' on the screen. Could this be happening because the feature is still in preview? Thank youSolved2.6KViews1like7CommentsSAP Mirroring in Microsoft Fabric with SAP Datasphere How to - Part 1 SAP
In this article, I walk through the complete process of replicating data from an SAP S/4HANA system into Microsoft Fabric. Part 1 focuses entirely on the SAP landscape. This includes the installation and configuration of the SAP Cloud Connector, the setup of the connection to SAP Datasphere, and the integration of all required internal SAP resources. In addition, the necessary prerequisites are described to ensure that the SAP environment is fully prepared for data replication. Part 2 continues with the configuration inside SAP Datasphere, where the source and target systems are connected and the replication flow is created. After completing the SAP-side setup, Part 2 then transitions into Microsoft Fabric, showing how the replicated SAP data is connected, stored, and made available through Azure Data Lake Storage Gen2 and the Mirrored SAP Database. This results in a complete end-to-end pipeline bringing SAP data reliably into Microsoft Fabric for analytics and reporting. Here you can direct go the Part 2. https://community.fabric.microsoft.com/t5/Data-Factory-Community-Blog/SAP-Mirroring-in-Microsoft-Fabric-with-SAP-Datasphere-How-to/ba-p/5138853 Also you can read the full Blog Article on my own Blog Site. https://renefuerstenberg.de/microsoftfabric/sap-mirroring-in-microsoft-fabric-with-sap-datasphere-step-by-step-guide/#more-12097.4KViews1like0Comments