Forum Discussion
Can Multiple Power BI Datasets Refreshing Against the Same SQL View Cause Deadlocks?
We are investigating a SQL Server deadlock during Power BI dataset refresh and would like clarification on whether the report architecture could be contributing to the issue.
Environment:
Power BI Import Mode
SQL Server source
Multiple PBIX files / semantic models consume the same database view (MOS_REPORT_V)
Scheduled refreshes run throughout the day
SQL Server occasionally reports deadlock victim errors (Error 1205)
Questions:
Is there any Microsoft-recommended limit on the number of Power BI datasets/PBIX files that can point to the same SQL Server view?
If multiple Power BI datasets refresh simultaneously against the same SQL view, can this contribute to SQL Server blocking or deadlocks?
Have others observed deadlocks caused by concurrent Power BI refreshes against a shared source view, even when the reports are independent?
Is it considered a best practice to consolidate reports into a shared semantic model/dataset instead of having multiple datasets independently querying the same database view?
From a Power BI perspective, would multiple datasets pointing to the same view be expected behavior, with deadlocks being primarily a SQL Server workload/concurrency issue?
Any guidance from Microsoft documentation, team guidance, or real-world experience would be appreciated.
Hi manoj_0911,
Hope you're doing well!
Here are my answers according to my experience:
1) No. Microsoft does not publish or enforce any limit on how many Power BI datasets can point to the same SQL Server object. There is no architectural constraint on the Power BI side preventing this.
2) Yes, absolutely. In Import mode, each dataset refresh issues its own independent SELECT query against the source. If the view references underlying tables that have concurrent write activity (e.g., ETL jobs, inserts, updates), and SQL Server's isolation level involves shared locks, multiple concurrent readers can interact with writers to produce deadlock cycles. Even read-only SELECT statements can be deadlock victims under the default READ COMMITTED isolation level with lock-based reads, specifically when lock escalation, page-level locking, or table scans are involved.
3) Yes, this is a well-documented pattern in the SQL Server and Power BI community. The typical scenario is:
- Multiple Power BI refreshes issuing full table scans via a shared view
- Concurrent ETL or data loading processes holding or acquiring conflicting locks
- SQL Server choosing a Power BI session as the deadlock victim (Error 1205)
It's less common when the source is purely read-only at refresh time, but not rare in mixed-workload environments.
4) Yes, Microsoft explicitly recommends this pattern. The guidance is to build a single, shared certified/promoted semantic model that other reports connect to via live connection or DirectQuery to the semantic model (composite models). This approach:
- Eliminates redundant refresh executions against the source
- Reduces source system load proportionally to the number of datasets consolidated
- Centralizes refresh scheduling, reducing concurrency peaks
- Aligns with the "thin report" model advocated in Microsoft's enterprise BI guidance
This is documented under the Power BI usage scenarios: Managed self-service BI and the semantic model best practices guidance.
5) Partially correct framing. Multiple datasets pointing to the same view is valid and expected Power BI behavior, Power BI has no knowledge of or coordination with other datasets hitting the same source. There is no cross-dataset refresh orchestration. So from Power BI's perspective, each dataset is simply doing its job.
However, the deadlock itself is a SQL Server workload management problem. The contributing factors are on the SQL Server side:
- Isolation level in use (READ COMMITTED with locking vs. READ COMMITTED SNAPSHOT ISOLATION / RCSI)
- Presence of concurrent write activity during refresh windows
- Index coverage on the underlying tables (scans vs. seeks)
- Lock granularity and escalation behavior
The most effective mitigation is enabling RCSI (Read Committed Snapshot Isolation) on the source database, which eliminates reader-writer blocking entirely by using row versioning. This is the standard recommendation for SQL Server databases serving BI workloads.
Hope this helps you! Don't forget to accept as solution ✅ and like it 👍 in order to keep helping others.
Best regards,
Oussama (Data Consultant - Expert Fabric & Power BI)
2 Replies
Hi manoj_0911,
Hope you're doing well!
Here are my answers according to my experience:
1) No. Microsoft does not publish or enforce any limit on how many Power BI datasets can point to the same SQL Server object. There is no architectural constraint on the Power BI side preventing this.
2) Yes, absolutely. In Import mode, each dataset refresh issues its own independent SELECT query against the source. If the view references underlying tables that have concurrent write activity (e.g., ETL jobs, inserts, updates), and SQL Server's isolation level involves shared locks, multiple concurrent readers can interact with writers to produce deadlock cycles. Even read-only SELECT statements can be deadlock victims under the default READ COMMITTED isolation level with lock-based reads, specifically when lock escalation, page-level locking, or table scans are involved.
3) Yes, this is a well-documented pattern in the SQL Server and Power BI community. The typical scenario is:
- Multiple Power BI refreshes issuing full table scans via a shared view
- Concurrent ETL or data loading processes holding or acquiring conflicting locks
- SQL Server choosing a Power BI session as the deadlock victim (Error 1205)
It's less common when the source is purely read-only at refresh time, but not rare in mixed-workload environments.
4) Yes, Microsoft explicitly recommends this pattern. The guidance is to build a single, shared certified/promoted semantic model that other reports connect to via live connection or DirectQuery to the semantic model (composite models). This approach:
- Eliminates redundant refresh executions against the source
- Reduces source system load proportionally to the number of datasets consolidated
- Centralizes refresh scheduling, reducing concurrency peaks
- Aligns with the "thin report" model advocated in Microsoft's enterprise BI guidance
This is documented under the Power BI usage scenarios: Managed self-service BI and the semantic model best practices guidance.
5) Partially correct framing. Multiple datasets pointing to the same view is valid and expected Power BI behavior, Power BI has no knowledge of or coordination with other datasets hitting the same source. There is no cross-dataset refresh orchestration. So from Power BI's perspective, each dataset is simply doing its job.
However, the deadlock itself is a SQL Server workload management problem. The contributing factors are on the SQL Server side:
- Isolation level in use (READ COMMITTED with locking vs. READ COMMITTED SNAPSHOT ISOLATION / RCSI)
- Presence of concurrent write activity during refresh windows
- Index coverage on the underlying tables (scans vs. seeks)
- Lock granularity and escalation behavior
The most effective mitigation is enabling RCSI (Read Committed Snapshot Isolation) on the source database, which eliminates reader-writer blocking entirely by using row versioning. This is the standard recommendation for SQL Server databases serving BI workloads.
Hope this helps you! Don't forget to accept as solution ✅ and like it 👍 in order to keep helping others.
Best regards,
Oussama (Data Consultant - Expert Fabric & Power BI)
Hi manoj_0911 ,
Thanks for reaching out to Microsoft Fabric Community.Just wanted to check if the response provided by oussamahaimoud was helpful. If further assistance is needed, please reach out.
Thank you oussamahaimoud for providing detailed response and contributing to the community.
