Azure Data Factory中如何获取Copy Data活动的总行插入数并避免生成多条日志记录

我完全理解你遇到的困扰——在ForEach循环批量加载表时，用Copy Data活动的输出插入日志总会出现多条记录，既有分批的行数又有最终总行数，只想保留单条总行数日志对吧？这其实是因为你可能误捕获了Copy活动的中间进度输出，或者日志插入的时机没选对。下面给你几个针对性的解决方案：

核心原因分析 #

ADF的Copy Data活动在运行过程中，会实时输出中间批次的处理进度（比如每完成一个写入批次就输出一次当前复制的行数），但只有当整个Copy活动完全成功完成后，@activity('Copy data').output.rowsCopied才会返回最终的总行数。你看到的多条日志，大概率是因为日志插入逻辑触发了这些中间进度事件，而不是等待活动完成后的最终结果。

解决方案1：调整控制流，确保只在Copy活动完成后插入一次日志 #

这是最直接有效的办法，把日志插入操作放在Copy活动的成功分支之后，确保只执行一次：

• 在ForEach循环的迭代内部，按顺序排列活动：
  1. 执行你的Copy data活动（建议给它起个清晰的名字，比如Copy [@{item().TableName}] to sink，方便后续引用）
  2. 添加一个用来插入日志的活动（比如Stored Procedure活动、SQL脚本活动）
  3. 在日志活动的参数/脚本中，引用@activity('Copy data').output.rowsCopied作为总行数

这样一来，只有当整个Copy活动成功跑完，才会触发日志插入，这时候获取的rowsCopied就是最终的总插入行数，不会出现分批的数值。

解决方案2：优化Copy活动配置，减少中间输出干扰 #

你已经设置了Degree of copy parallelism = 1、写批处理大小留空，这个配置没问题，还可以再检查这两点：

• 关闭Copy活动的详细日志记录：在Copy活动的"Settings"标签下找到"Logging"，确保只勾选"Enable logging"而不是"Enable detailed logging"，减少中间进度输出的干扰。
• 检查重试机制：如果Copy活动设置了重试次数，重试过程中可能会产生额外输出，但只要你是在活动成功后执行日志插入，就只会记录最后一次成功的总行数。

解决方案3：用变量暂存总行数（适用于复杂场景） #

如果你的管道逻辑需要对行数做额外计算，可以在ForEach循环内部先定义一个整数变量（比如totalRowsCopied）：

• 在Copy活动完成后，添加一个Set Variable活动，把变量值设为@activity('Copy data').output.rowsCopied
• 然后在日志插入活动中引用这个变量的值

这种方式能确保你拿到的是活动结束后的最终数值，避免直接引用活动输出可能出现的意外。

备注：内容来源于stack exchange，提问作者skyline01