你能帮我完成工作表现吗？我用10个AU运行它 . 并且在最初的部分时间它们几乎全部被使用 . 但是从执行时间的后半段开始，它仅使用1个AU . 我在计划中看到一个超级变换仅由一个顶点组成，它看起来像是低估了执行计划（它只是假设） .
我正在尝试分析执行时间，但如果没有像HashCombine，HashCross等操作的技术描述那么很难......
所以我的问题可以用它做一些事情（修改代码，添加提示等）？
The problem was fixed with Mychael Rys's solution.
我应用了Michael Rys的解决方案，它完美无缺 . 一如既往地谢谢你！见下图 . 几乎所有10AU的10AU现在都在使用 . 我也使用了建模工具，看起来脚本被线性缩放 . 太棒了:) .
One more solution
我也可以通过左连接替换内部连接（替换在我的情况下是等效的，因为在维度表中，对于事实表dim-1中的任何记录，ALWAYS只存在一行：M-fact） . CBO估计加入的结果基数为“至少不低于事实表” . 在这种情况下，CBO生成没有提示的良好计划 .
1 回答
我会将您的工作链接转发给我们的开发人员，他们可以在我获得更多信息后查看并更新此答案 .
但是对于stackoverflow帮助，查看脚本和/或作业图也会很有帮助 . 例如，您运行了多少数据？您使用的是暗示订购或分组等的操作吗？
基于顶点执行视图，您似乎从许多小文件中提取每个文件只包含少量数据 . 很可能优化器假设只有少量数据来自这些文件 .
假设我的初始假设是正确的，您可以在
EXTRACT语句中添加OPTION(ROWCOUNT= xxx)提示以提示更多行（xxx将是强制系统并行化的数字） .Some Additional Information after looking at the job
该计划是一个13向连接，包含12个维度表和1个事实表 . 12个连接中的9个完成后，错误（低估导致串行计划）开始 . 最后3个连接 - 使用dim_application，dim_operation和dim_data_type，是连续完成的 . 计划的主干仍然有29GB . 由于我们没有外键信息，因此我们很难通过9个连接进行估算 .
你可以做的最有可能的事情是做这项工作
将join语句拆分为2，其中第二个连接为dim_application，dim_operation和dim_data_type .
使用大数字在第一个连接语句的输出上添加
ROWCOUNT提示 .如果有帮助，请告诉我 .