Informatica长耗时作业排查：定位Sorter或源Oracle SQL瓶颈

性能瓶颈完全来自源端Oracle SQL查询与数据读取环节，Sorter转换组件不存在任何性能问题。

逐行对齐会话日志时间戳可直接验证结论：

• 2022-06-26 23:40:13：Informatica Reader组件向Oracle数据库下发源端查询SQL
• 2022-06-26 23:49:01：Oracle向Reader返回首行查询结果，该阶段SQL初始执行耗时8分48秒；Sorter组件在首行数据返回后1毫秒即启动，开始逐行接收Reader传递的数据
• 2022-06-27 03:04:51：Reader组件完成全部410516行数据读取，从首行返回到全量数据读取完成累计耗时3小时15分50秒；Sorter组件在Reader读完后8毫秒即完成全部输入数据接收
• 2022-06-27 03:04:52：Sorter组件完成全量数据排序、输出操作，实际排序逻辑执行总耗时仅0.27秒。日志明确标注临时I/O字节数为0，说明总大小仅6.5MB左右的输入数据完全在内存中完成排序，无磁盘落盘开销
• 2022-06-27 03:04:52：Writer组件启动目标表加载，03:09:47完成加载，累计耗时约5分钟，属于正常写入性能范围

观察到的「Sorter转换启动后总耗时超3小时」是对Informatica流水线执行机制的误解：Informatica采用流式流水线处理逻辑，下游组件不会等上游组件全量处理完才启动，而是上游每读出一行就向下游传递一行。Sorter启动后的绝大多数时间都处于等待Reader传输数据的空闲状态，并未执行实际排序计算——Sorter作为阻塞型组件，只有收齐所有输入数据后才会触发排序动作，这一步在当前日志中仅耗时不到1秒。

• 优先排查优化源端Oracle SQL：拉取SQL执行计划，检查是否存在全表扫描、多表关联无有效索引、过滤条件未下推、不必要的复杂计算等问题，直接优化SQL执行效率
• 排查源库与Informatica服务器之间的网络链路，确认是否存在带宽不足、防火墙限流、跨网传输延迟高等问题
• 检查SQL执行时段Oracle数据库的资源负载，确认是否存在CPU/IO资源被其他高负载作业抢占、查询被锁阻塞等情况，导致结果集返回速度异常
• 现有Sorter组件配置无需调整，6.5MB的输入数据量远低于Sorter默认内存阈值，不存在内存不足导致的性能问题

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