根据你描述的场景——单ODBC表处理正常，多表就失败，大概率是并发处理、连接配置或者查询逻辑的冲突问题，给你几个针对性的排查和解决方向：

1. 限制SSAS并行处理度 #

SSAS默认会并行处理多个表，这可能触发数据源的并发连接限制，或者导致ODBC连接池冲突。你可以尝试降低并行度来验证：

• 在Visual Studio的Tabular模型项目中，右键模型（Model.bim）选择Properties
• 找到MaxParallelism属性，把默认值（通常是8或者服务器核心数）改成1或者2
• 重新尝试Build、Process操作，如果成功，说明是并发连接导致的问题，后续可以根据数据源的最大连接数调整这个值

2. 检查SQL查询的会话级冲突 #

如果你的查询用到了临时表（比如#temp）、会话变量或者依赖会话级别的设置，多表并行处理时会因为共享同一个ODBC会话导致冲突：

• 把会话级临时表改成全局临时表（##temp），或者给每个查询的临时表加唯一后缀（比如#temp_Customer、#temp_Order）
• 尽量用CTE（公共表表达式）代替临时表，避免会话级资源竞争
• 检查查询中是否有SET语句（比如SET DATEFORMAT），这类语句会影响整个会话，多表并行时可能干扰其他查询

3. 排查单表单独处理的可行性 #

先单独处理新增的那张表：

• 在SSMS中连接到Azure SSAS，右键新增的表选择Process Table > Process Full
• 如果单独处理失败，说明这张表的SQL查询有语法错误、权限问题或者数据源对象不存在，仔细核对查询语句和数据源权限
• 如果单独处理成功，那问题肯定出在多表并行处理的连接配置上，回到步骤1或者调整ODBC连接池设置

4. 查看详细处理日志定位错误 #

没有具体错误信息很难精准排查，你可以开启SSAS处理日志获取细节：

• 在Visual Studio中启动Process操作时，勾选窗口底部的Enable logging
• 处理失败后，打开生成的日志文件（通常在项目的bin目录下），查找包含Error或者Failed的条目，里面会有具体的错误代码和描述（比如连接超时、权限不足、SQL执行失败）

5. 验证ODBC驱动与连接池设置 #

• 确保你使用的是数据源对应的最新ODBC驱动（比如针对SQL Server用ODBC Driver 18 for SQL Server，针对Oracle用官方ODBC驱动），旧驱动可能存在并行连接的兼容性问题
• 打开ODBC数据源管理器，找到你的数据源，进入Connection Pooling设置，尝试禁用连接池（或者调整超时时间），再重新处理模型

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