Forum Discussion

FabricEnjoyer's avatar
FabricEnjoyer
New Member
20 days ago
Solved

Mirroring 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?

  1. What specifically contributes to Warehouse SQL Endpoint Query Usage for an Open Mirroring Database?
  2. Do any of the internal mirroring processes execute through the SQL Endpoint and therefore appear under this metric?
  3. Did the recent Fabric metering changes alter how these operations are classified or billed?
  4. What exactly does the "User" identity represent in the Run By filter?
  5. Why did individual user identities disappear after 10 August and become a generic "User" value?
  6. Is the new User Identity dimension connected to the recent metering changes?
  7. 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!

  • Hi v-achippa​  and JVDA98​ 

    I just had a call with Microsoft Support and was informed that this is indeed a result of the new metering system. SQL usage is now aggregated at the workspace level rather than being attributed to individual users, which explains the behavior we are seeing.

    Kind regards,
    Nichael

6 Replies

  • v-achippa's avatar
    v-achippa
    Community Support

    Hi FabricEnjoyer​,

    Thank you for the update and for confirming the information from Microsoft Support. Glad to know the issue has been resolved. Thank you for being part of Microsoft Fabric Community.

    Thanks and regards,
    Anjan Kumar Chippa

  • Hi v-achippa​  and JVDA98​ 

    I just had a call with Microsoft Support and was informed that this is indeed a result of the new metering system. SQL usage is now aggregated at the workspace level rather than being attributed to individual users, which explains the behavior we are seeing.

    Kind regards,
    Nichael

  • v-achippa's avatar
    v-achippa
    Community Support

    Hi FabricEnjoyer​,

    As we haven’t heard back from you, we wanted to kindly follow up to check if your issue is resolved? or have you raised a support ticket?

    Thanks and regards,
    Anjan Kumar Chippa

  • v-achippa's avatar
    v-achippa
    Community Support

    Hi FabricEnjoyer​,

    Thank you for reaching out to Microsoft Fabric Community.

    The increase in sql endpoint query CU is most likely related to the recent fabric metering change for warehouse or sql endpoint workloads. This can report higher CU usage, especially for frequent or short running queries, this does not indicate an issue with the open mirroring setup.

    The generic User value is a separate issue. Please verify that Show user data in the Microsoft Fabric Capacity Metrics app and reports is enabled under the Fabric Admin portal --> Tenant settings --> Audit and usage.

    If that setting is already enabled and individual users are still being shown only as User, please raise a Microsoft support ticket so that the team can check the user attribution behaviour.

    Create a Fabric and Power BI Support Ticket - Power BI | Microsoft Learn

    Thanks and regards,
    Anjan Kumar Chippa

    • FabricEnjoyer's avatar
      FabricEnjoyer
      New Member

      Hi v-achippa​ 

      Thank you for your response.

      I had a look at the settings, and it appears that everything is enabled as expected.

      I will log a support ticket with Microsoft to investigate this further.

      Thank you.

      • JVDA98's avatar
        JVDA98
        Frequent Visitor

        Just checking in if you had any feedback so far on this. We are having the same issue on different tenants regarding the "user". 

        Regarding the exploded CU-usage, I am trying a bit with Custom SQL Pools to reduce the load, but this is not working for each increase we've seen. 

        Succesfully reduced the CUs needed to refresh Power BI Semantic Models, but queries / paginated reports still stay inflated since 11/08.