Power BI数据刷新超时故障排查求助（含Simba ODBC报错）

我之前处理过好几起Power BI通过Simba ODBC连接BigQuery时的刷新超时问题，结合你给出的日志和已经做的操作，给你梳理下具体的排查思路和相关的知识点：

首先得区分哪些是“干扰项”，哪些是核心问题：

• 反复出现的SQLGetInfo property not found: 180/1750：这类错误其实是ODBC驱动在尝试获取BigQuery不支持的ODBC标准属性（180对应SQL_MAX_COLUMN_NAME_LEN，1750对应SQL_DRIVER_HDESC），属于驱动兼容性的小问题，本身不会直接导致超时，但如果驱动在反复重试获取这些属性时产生了额外开销，可能会成为超时的诱因，可以暂时忽略，先聚焦核心错误。
• 单次出现的HTTP error: Error encountered during execution. Retrying may solve the problem：这个才是关键！它直接指向BigQuery API在执行查询时遇到了异常，虽然提示可以重试，但大规模数据刷新时，重试机制扛不住持续的异常，最终就会触发Power BI网关的超时。

1. 先定位到具体的问题数据集 #

你提到小型刷新正常，说明问题出在特定的大表或复杂查询上：

• 逐个移除Power BI数据集里的表，每次刷新测试，精准找到触发超时的那张/那几张表；
• 针对可疑表，检查是否存在：
  • 超长字符串字段：比如超过BigQuery STRING类型的最大限制（或Power BI无法处理的超长文本），或者包含非UTF-8的乱码、不可打印字符；
  • 异常数据类型：比如BigQuery里的JSON、ARRAY等复杂类型，在ODBC驱动转换时出现异常；
• 查看该表对应的查询语句，是否有复杂的多表JOIN、嵌套聚合、窗口函数，导致BigQuery执行时间过长，超过了Power BI网关的默认超时阈值（默认1小时，可以临时调高测试，但不建议长期依赖）。

2. 优化BigQuery端的查询性能 #

从数据源端减少压力是最有效的办法：

• 给大表添加分区键和聚簇键，大幅减少查询扫描的数据量；
• 把Power BI里的复杂计算逻辑，提前在BigQuery端创建视图完成预计算，避免在Power BI加载时做大量运算；
• 去BigQuery控制台的「查询历史」里查看对应刷新任务的详细错误（比ODBC日志更准确），看是否存在配额超限、资源耗尽的情况（比如并发查询太多，导致查询排队超时）。

3. 调整ODBC驱动的高级配置 #

虽然你已经更新了驱动，但可以试试这些参数调整：

• 打开ODBC数据源管理器，找到你的BigQuery数据源，进入「Advanced」标签；
• 开启Enable Query Cache，利用BigQuery的查询缓存减少重复计算；
• 把Query Timeout设置为更大的值（比如3600秒），避免驱动层面提前终止查询；
• 确认Use Legacy SQL是关闭状态，确保使用标准SQL语法，减少兼容性问题。

4. 检查Power BI网关的细节 #

• 确认网关服务器在刷新时段没有其他大流量任务占用带宽；
• 查看网关自身的日志（不是ODBC日志），看是否存在网关进程内存/CPU占用过高，导致无法处理刷新请求；
• 如果业务允许，把数据集的刷新模式从「完整刷新」改成「增量刷新」，减少每次刷新的数据量。

• Magnitude官方文档明确提到，SQLGetInfo的未实现属性错误属于非致命错误，无需过度关注，只要驱动版本与Power BI网关兼容即可；
• BigQuery官方文档指出，这类HTTP执行错误常见于查询资源耗尽、数据格式不兼容、配额超限三种情况，必须结合BigQuery控制台的查询历史来定位具体原因；
• Power BI网关的超时设置可以在「网关集群设置」->「高级」里调整，最大不超过5小时，但要注意服务器的资源承载能力。

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