SSIS包运行过慢排查及数据拉取状态确认技术问询

一、运行缓慢及PrimeOutput后停滞的原因 #

1. ADO NET源对DAX查询的适配低效 #

手动查询工具（如SSMS、Tabular Editor）直接对接SSAS Tabular引擎，针对DAX结果做了流式返回优化；但SSIS的ADO NET源是通用组件，没有针对DAX的多维结果集做特殊适配，需要额外将多维行集转换为关系型行集，这个转换过程会产生大量开销，拖慢数据拉取速度。

2. 目标库写入瓶颈反向阻塞数据流 #

虽然用了OLE目标的「快速加载」模式，但Azure数据库S4层（DTU 200）的写入吞吐量不足——从目标库10~20分钟仅加载5万行的情况来看，写入时可能遇到锁等待、事务日志写入压力等问题。SSIS数据流是管道式处理，下游写入慢会反向阻塞上游源端的数据推送，导致源端拉取被迫降速，这是核心瓶颈之一。

3. 数据流组件间协调效率低 #

SSIS IR的CPU（20_{40%）和内存（4}12GB）未跑满，说明不是IR资源限制，而是数据流组件间的行集转换、数据类型适配等环节效率低下，导致数据流动不顺畅，整体吞吐量被拉低。

4. PrimeOutput后停滞的具体原因 #

PrimeOutput是数据流引擎通知源组件开始输出数据的阶段，停滞大概率是以下情况：

• 下游目标组件写入阻塞，导致源组件无法继续输出数据（数据流双向反馈，下游缓冲区满则上游暂停）；
• SSAS端DAX查询的后续数据块生成缓慢——虽然内存未达上限，但DAX查询的计算复杂度可能导致后续数据块的生成耗时增加；
• ADO NET源与SSAS的连接出现传输延迟，导致数据无法持续推送。

5. 手动查询与SSIS包的效率差异 #

手动查询仅需完成「SSAS计算+结果返回客户端」两个步骤，没有SSIS数据流的转换、目标写入等额外环节；且工具用了SSAS原生接口读取结果，效率远高于通用的ADO NET组件，因此耗时差距极大。

二、源端数据拉取完成的确认方法及相关疑问 #

1. 确认源端已拉取全部数据的方式 #

• 查看SSIS详细日志：开启组件级日志后，搜索「数据流任务：已完成从源组件读取所有行」类记录；或在SSIS执行报告中，查看ADO NET源的「读取行数」是否等于DAX查询预期的500万行。
• 监控SSAS端会话：用SSMS连接SSAS，通过DMV $SYSTEM.DISCOVER_SESSIONS 和 $SYSTEM.DISCOVER_COMMANDS 查看对应DAX查询的会话状态，若会话已结束（无Running状态的查询），说明源端已返回全部数据。
• 监控网络传输：在SSIS IR所在VM上用网络工具（如Wireshark）查看与SSAS的连接，若连接已关闭或长时间无数据传输，且目标库仍在写入，说明源端已拉完数据，剩余为内存缓存数据的写入。

2. 目标库有数据加载≠源端拉完并缓存 #

SSIS数据流是流式处理，源端拉取一部分数据后会立即推送给目标组件写入，无需等待全部数据拉取完成。因此目标库有数据加载仅能说明源端已开始拉取数据，无法确认全部数据已拉取完成。只有同时满足以下条件，才能确认：

• SSIS源组件的读取行数达到预期值；
• SSAS端对应DAX查询的会话已结束；
• 目标库的写入行数与源端读取行数一致。

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