Azure Data Factory中Copy Activity的幕后工作原理是什么

首先直接回答核心问题：该场景下Copy Activity默认不会通过SQL存储过程完成数据移动，所有内置数据流转逻辑都不需要依赖Oracle侧部署的自定义存储过程，具体运行流程拆解如下：

• 连接建立阶段：部署在本地环境的自承载集成运行时（SHIR）会通过内置的ODP.NET驱动和本地Oracle建连，同时通过公网/专线和ADLS Gen2建立DFS API连接，整个建连过程不会在Oracle侧创建任何对象。
• 源端数据读取阶段：
  • 无自定义配置的默认场景下，SHIR只会自动生成标准的SELECT 配置列 FROM 源表查询语句拉取数据；如果开启了并行读取，会根据选择的分区策略（Oracle原生分区/自定义数值分区列）拆成多个带范围条件的SELECT子查询并行拉取，全程不会生成、调用任何PL/SQL存储过程。
  • 只有手动在源配置里指定了自定义查询语句、或者主动选择调用存储过程作为数据源时，才会执行用户自定义的SQL/存储过程，这属于主动配置的行为，不是Copy Activity的默认移动逻辑。
• 数据处理阶段：所有类型映射、格式转换、字段映射、压缩编码这类逻辑都是在SHIR本地节点的内存/本地临时缓存中完成，不会把处理逻辑下推到Oracle端通过存储过程执行。
• 数据写入阶段：处理完成的文件数据直接通过ADLS Gen2的DFS接口写入目标存储，整个写入环节和Oracle侧完全解耦，不存在调用存储过程的可能。

常见误区澄清：有部分传统ETL工具会在源库创建临时存储过程做数据抽取，但ADF的Oracle连接器在源是Oracle、接收端是文件类存储（比如Gen2）的场景下，全程只会对Oracle执行只读SELECT查询，不会在库中创建临时存储过程、自定义函数这类对象，也不会执行任何非查询类的PL/SQL语句，除非用户自己在源配置里主动写了对应逻辑。

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