Power BI服务无法呈现分页报表：无法创建数据源连接

一、服务器/容量性能相关排查点 #

• 监控Power BI高级容量资源负载：查看Admin Portal中容量的CPU、内存、磁盘IO峰值，重点关注报表执行时段的资源使用率。如果容量VM节点被其他报表/数据集抢占资源，会导致间歇性超时或报错。
• 检查Azure SQL数据库性能：
  • 用Query Store分析存储过程的执行计划，确认是否存在统计信息过期导致的执行计划退化，这会引发间歇性慢查询。
  • 查看数据库的等待事件、锁阻塞情况，排查多个存储过程并发访问时的资源冲突。
  • 监控SQL数据库的CPU、IO使用率，确认是否在报错时段出现资源耗尽。

二、报表与数据集配置问题 #

• 50个数据集并发执行冲突：多个存储过程同时访问同一数据源对象时，易引发锁等待或资源争抢。可尝试调整存储过程的隔离级别（如启用READ_COMMITTED_SNAPSHOT），或优化存储过程的事务逻辑，减少锁持有时间。
• 数据集刷新策略：若设置了所有数据集同时刷新，会瞬间触发大量并发请求，超出容量或数据源的处理能力。可调整为错开的刷新时间窗口，或分批次执行数据集刷新。
• 缓存失效触发的重新查询：若报表依赖缓存，缓存过期时会重新查询数据源，此时若数据源压力过大就会报错。检查缓存过期时间是否合理，可适当延长缓存时长。

三、容量配置与阈值检查 #

• 高级容量SKU适配性：若近期报表数据量增长或新增了其他BI负载，原SKU的资源可能不足以支撑。检查容量的并发会话数、查询吞吐量是否达到阈值。
• 容量节点健康状态：确认高级容量的VM节点是否存在临时故障或重启记录，节点不稳定也会导致间歇性报错。

四、快速验证步骤 #

1. 在报错时段，分别查看Power BI容量指标和Azure SQL Query Store日志，定位资源瓶颈。
2. 在SSMS中手动执行单个存储过程，重复多次，确认是否存在间歇性执行缓慢的情况。
3. 临时调整数据集刷新策略，改为串行执行，观察报错是否消失，验证并发冲突是否为诱因。

内容的提问来源于stack exchange，提问作者Etienne