Forum Discussion
Kudo CommanderXMLA Query Overload – 2_PROD Dataset Caused 30% I/O Spike & Failure
Hello Power BI Community,
We’re encountering a critical issue with one of our production datasets in the Power BI Service:
Date/Time of Incident: July 29, 2025, around 2:15–3:00 PM PST
During this window, a user attempted to query the dataset via XMLA endpoint, which triggered an expensive I/O operation that consumed approximately 30% of our organization’s total Power BI processing capacity, ultimately causing a query failure and performance disruption.
We would like support on the following:
Root Cause Analysis of what happened during the XMLA operation.
We suspect the XMLA connection was initiated from Excel or an external tool by a business user, which may have caused the I/O overload unintentionally. We dont have admin rights to the PowerBI Service.
License: Premium Capacity
SKU: P3, REGION: WEST US
Thank you,
Manoj Prabhakar S
Hi manoj_0911 ,
An unfiltered XMLA query (often from Excel or SSMS) can hit your dataset like a freight train and spike I/O in Premium capacity.
How to prevent it going forward:
-
Tighten XMLA permissions: Only grant access to specific users or service principals that actually need it.
-
Work with your admin to review Power BI audit logs/capacity metrics and pinpoint exactly who/what triggered the spike.
-
Educate your users: Remind everyone to use filters in Excel or any external tool, not just drag everything in.
-
Tune your dataset: Remove unused columns, split large tables, and use aggregations or pre-calculated tables for big reports.
-
Set up capacity alerts so you get notified before things go sideways next time.
-
5 Replies
- jaineshp
Memorable Member
Hi manoj_0911 ,
Looks like a heavy XMLA query caused a capacity spike. Some quick suggestions:
Check if the query was from Excel/SSMS via XMLA—likely an unfiltered pull.
Restrict XMLA access to only required users or service principals.
Review the dataset structure—remove unused columns or split large tables.
Use aggregations/pre-calculated tables for common queries.
Monitor capacity metrics to spot similar spikes early.
If you're not an admin, ask them to run a query trace for root cause.
Hope this helps!
Best Regards,
Jainesh Poojara | Power BI Developer 
rohit1991Super User
Hi manoj_0911 ,
An unfiltered XMLA query (often from Excel or SSMS) can hit your dataset like a freight train and spike I/O in Premium capacity.
How to prevent it going forward:
-
Tighten XMLA permissions: Only grant access to specific users or service principals that actually need it.
-
Work with your admin to review Power BI audit logs/capacity metrics and pinpoint exactly who/what triggered the spike.
-
Educate your users: Remind everyone to use filters in Excel or any external tool, not just drag everything in.
-
Tune your dataset: Remove unused columns, split large tables, and use aggregations or pre-calculated tables for big reports.
-
Set up capacity alerts so you get notified before things go sideways next time.
-
v-ssriganeshCommunity Support
Hello manoj_0911,
Hope everything’s going great with you. Just checking in has the issue been resolved or are you still running into problems? Sharing an update can really help others facing the same thing.
Thank you.
- v-ssriganesh
Hi manoj_0911,
Thank you for posting your query in the Microsoft Fabric Community Forum, and thanks to rohit1991 & jaineshp for sharing valuable insights.
Could you please confirm if your query has been resolved by the provided solutions? This would be helpful for other members who may encounter similar issues.
Thank you for being part of the Microsoft Fabric Community.
- v-ssriganesh
Hello manoj_0911,
We hope you're doing well. Could you please confirm whether your issue has been resolved or if you're still facing challenges? Your update will be valuable to the community and may assist others with similar concerns.
Thank you.
