简介：面向 Informatica 数据集成开发者的图文操作指南，聚焦“调用存储过程”这一高频需求。资源以 docx 文档形式呈现，共 1 个文件，压缩包大小约 180KB，内容紧凑，尤其适合刚接触 Mapping 的初学者快速掌握 pre SQL 调用存储过程的实施方法。文档从新建 Mapping、右键目标表进入属性选项卡，到在 pre SQL 栏写入调用脚本、利用变量替换入参，再到保存运行，形成完整闭环；同时补充了存储过程的定义、使用优势（批量执行、权限控制、数据一致性）以及数据迁移、同步、报表生成等典型应用场景，帮助读者理解调用前后的完整逻辑。已有 975 人学习下载，可作为 Informatica 开发与运维人员的查阅备查资料。通过图文对照，读者能少走弯路，直接复用关键配置步骤，提升数据集成任务的处理效率。无论是开发调试还是后期维护，均可按图索骥。
1. Informatica调用存储过程：ETL开发里绕不开的那道坎
做数据集成的人迟早会遇到这种场景：目标表要按复杂业务逻辑做月度结转，源库几十张表先清洗再合并，报表口径一变，连写带调要改一大片 Mapping。Informatica 里堆转换组件看似万能，真碰上批量 UPDATE、跨表回填、Oracle 存储过程里那套游标计算，纯拖组件又慢又难维护。于是“Informatica 调用存储过程”成了很多 ETL 项目的必修课：要么把存储过程当数据源读返回结果集，要么在映射中执行它完成写库动作。这篇文章写给正在用 PowerCenter 做数仓、又不得不和数据库存储过程打交道的开发与运维。我不堆概念，直接按我平时做项目的手顺，把导入、绑定、传参、排错一条线讲完，每一步给出可照做的配置和参数。
2. 调用存储过程的选型与前置条件：为什么不用 Mapping 硬算
2.1 三个典型场景，哪些该用存储过程
我在项目里总结下来，真正值得在 Informatica 里调存储过程的场景就三类。第一类是目标表要做整表级操作，比如月底先把汇总表清空，再按新口径重刷，这种逻辑用 Mapping 里的 Update Strategy 做很啰嗦，而且中间结果集一大，Session 性能就崩。第二类是复杂业务校验，比如主数据去重、分数修正、跨多张表的关联回填，这种规则的载体本来就该在数据库端，用 SQL 写比在 Mapping 里串十几层表达式可靠。第三类是性能敏感的就地更新，数据量大时靠数据库端批量提交、减少网络回传，比 Informatica 逐行推送到目标端快一个量级。
反过来也要泼一盆冷水：能用 Lookup、Joiner、Expression 完成的简单转换，不要硬套存储过程。调用存储过程会让 Mapping 的可读性和依赖关系变差，DBA 改一次存储过程，ETL 这边就要跟着回归。我的原则是“存储过程只承载数据库擅长的写入逻辑，ETL 只负责抽取、转换和调度”，这样两边边界清楚，出问题也好定位。
2.2 调用方式选型：作为数据源、目标还是转换
Informatica 调用存储过程不是只有一种姿势，常见做法分三种。一种是作为数据源，存储过程返回 Oracle REF CURSOR 或结果集，PowerCenter 在 Source Analyzer 里导入存储过程元数据，然后像普通表一样去读。第二种是作为目标，Target 类型选择 Stored Procedure，也就是让 ETL 把每行数据作为参数传给存储过程去执行写库。第三种是作为独立的 Stored Procedure Transformation，放在映射中间执行一段 SQL 或存储过程，用于做定制化动作，比如调用存储过程完成预处理。
三种方式怎么选？我一般看数据流的方向：要“读”就用数据源方式，要“写”就用目标方式，要做映射过程中的旁路动作，用转换方式。很多新手一上来就在映射里拖一个 Stored Procedure Transformation，结果输入输出端口不会配，连错半天。其实先想清楚数据是流入还是流出，架构就自然清楚了。
2.3 前置条件清单：先把存储过程本身跑通
正式在 Informatica 里操作之前，我建议先把下面这几项逐一确认，避免把数据库端的问题误判成 ETL 的问题。存储过程要能在数据库客户端里独立执行成功，包括入参、出参、异常分支都要测一遍；数据库账号要有执行该存储过程的权限，同时允许 Informatica 通过 ODBC/JDBC 连接；连接串要能连通，PowerCenter 的 Integration Service 所在机器能和数据库正常通信；目标表或临时表要存在，且字段类型与存储过程出入参兼容。
我习惯用一张小清单做记录，每项都打勾了才进 Designer。特别是权限问题，很多时候报“对象不存在”其实是账号没有执行权限，或者存储过程在另一个 Schema 下。先跑通存储过程本身，再谈 Informatica 调用，这条顺序不要颠倒。
3. PowerCenter Designer 配置存储过程转换：挂载、连库、绑参数的实操路径
3.1 在 Source Analyzer 导入存储过程作为数据源
如果你的存储过程返回的是一个结果集（比如 Oracle 的 REF CURSOR），我一般这样操作。先打开 Source Analyzer，右键工作区，选择 Import -> Stored Procedure。弹出的对话框里要填 ODBC 数据源、用户名、密码，选择要导入的存储过程名。这里有个细节：PowerCenter 读取的是存储过程签名，包括参数列表和返回类型，导入完成后工作区会生成一个 Source 定义，源字段对应存储过程的输出字段。
-- 以 Oracle 为例，一个返回游标的存储过程 CREATE OR REPLACE PROCEDURE GET_ACTIVE_EMPLOYEE ( DEPT_ID IN NUMBER, EMP_CUR OUT SYS_REFCURSOR ) AS BEGIN OPEN EMP_CUR FOR SELECT EMP_ID, EMP_NAME, SALARY FROM EMPLOYEE WHERE DEPT_ID = DEPT_ID; END;这段 SQL 注释一下要点：入参 DEPT_ID 是过滤条件，出参 EMP_CUR 是游标。导入时 PowerCenter 会把 EMP_CUR 识别成输出源，映射里就能直连 Source Qualifier。导入成功后，我通常先打开 Source Qualifier，检查“SQL Query”属性，确认生成的查询语句没有语法问题，再把端口拖到 Mapping 里和下游转换连线。
3.2 在映射中创建 Stored Procedure Transformation
如果要在数据流中间执行一个存储过程，那就进入 Mapping Designer，在菜单栏选择 Transformation -> Create，类型选 Stored Procedure。新建之后双击打开属性编辑器，需要配置几个关键项：连接信息、SQL 类型、存储过程名、参数映射。
连接信息上，常见做法是选择已有的 ODBC 连接，或者在属性里用连接变量 $SourceDB、$TargetDB 来引用。SQL 类型有 Static 和 Dynamic 两种。Static 表示存储过程名固定，解析时直接按名字调用；Dynamic 可以用端口值拼接存储过程名，支持运行时动态决定调用哪个过程，但写法更绕，报错也更难查。我平时不用 Dynamic，只有遇到“同一套 ETL 要切换不同月份存储过程”这类需求时才碰。
Stored Procedure 属性核心配置项： - Store Procedure Name: GET_ACTIVE_EMPLOYEE - SQL Type: Static - Connection: $TargetDB - Tracing Level: Normal参数映射是这里最容易出错的部分。在“Parameters”标签页里，入参和出参会以端口列表形式出现。入参要连到上游表达式的输出，出参要连到下游断口或表达式转换的输入；如果存储过程有 RETURN 返回值，还要在结果端口上单独绑定。连线完成后，Mapping 里看到的转化图标上就会带输入输出端口，和普通转换组件用法一致。
3.3 定义存储过程目标：让 ETL 写入变成过程调用
场景是“每来一行数据就调用一次存储过程写库”，这时候更推荐把存储过程定义为目标。在 Target Analyzer 里右键导入存储过程，PowerCenter 会生成一个 Stored Procedure Target。导入后打开 Target 定义，可以看到 Insert/Update 对应的 SQL 模板，里面是存储过程名以及各端口到参数的映射关系。
实际操作时，我通常把存储过程目标当作普通目标表对待，在 Mapping 里把上游端口连到目标端口，然后在 Session 里照常配置目标连接。区别在于，PowerCenter 不会生成 INSERT 语句，而是把目标端口值作为实参传给存储过程，由数据库端完成写入。里面有个性能点要特别注意：默认情况下一行一提交会很慢，建议在 Session 属性里把 Target Load 的 Bulk 模式打开，或者结合存储过程内部的批量处理设计。
3.4 保存、编译与生成 Session
配置完 Mapping 后先 Ctrl+S 保存，PowerCenter 会在保存时校验存储过程定义是否有效。最典型的问题就是存储过程名找不着，这时先回数据库确认 Schema。校验通过后，再到 Workflow Manager 里创建 Session，把源、目标连接重新映射到实际运行环境，编译工作流。编译报错大多出现在连接变量找不到、端口类型不匹配，日志里会有明确的错误码，顺着去查就行。
4. 传参与返回值：让数据流和存储过程真正握手
4.1 IN/OUT 参数如何绑定端口
很多人在“传参”这一步翻车，是因为没搞清楚参数方向。存储过程入参（IN）要从数据流里取数，所以映射中这个参数端口必须连接到上游转换的输出；出参（OUT）是存储过程回传的结果，要连接到能消费它的下游端口。双击 Stored Procedure Transformation 打开参数页，能看到参数名、方向、数据类型和端口映射四个要素。
常见错误是把入参端口留空，结果存储过程执行时报缺参。我一般习惯在映射里加一个 Expression 转换，专门用来给入参赋值，比如把源字段类型 varchar2 转成 number，或者在传参前做空值默认值处理。比如存储过程要求年份参数必须是四位整数，就在表达式里写 TO_INTEGER(SUBSTR(BIZ_DATE,1,4)) 再连给入参。这样可以提前拦截脏数据，而不是等存储过程炸了再回头查。
OUT 参数则要注意下游端口的容量。Oracle 的 Varchar2 出参可能很长，下游目标字段如果定义成 String(10)，数据就会被截断。虽然不会报错，但数据已经错了。所以每次配置 OUT 参数，我都会顺带检查目标端字段长度。
4.2 存储过程返回值与运行状态捕获
存储过程如果有 RETURN 返回值，PowerCenter 会提供一个返回值端口。这个端口可以接到表达式转换里做判断，比如返回 1 表示成功、0 表示失败，ETL 就能据此决定是继续数据流还是跳到错误分支。这个设计在接口类作业里特别有用，有点类似“API 调用”的语义：一次调用，回传状态码，上层决定后续动作。
返回值端口使用建议： - 返回值端口类型一般设为整型或字符串 - 在表达式转换中匹配返回码，生成错误标志字段 - 将错误标志写进日志表，便于调度平台统一监控要注意的是，有些数据库驱动下 RETURN 值并不会稳定回传，比如使用了批量提交或存储过程内部有 RAISE 异常时就拿不到。我一般不用 RETURN 值做最终判断，更依赖日志表里的写入记录和 Session log 里的行数统计来做交叉验证。这也是为什么运行状态捕获要放在整个调用流程之外单独做。
4.3 动态参数与替换变量
把 Session 参数传进存储过程是另一个常用能力。常见做法是在 Workflow Manager 里定义参数文件，设置 $MonthEnd、$BusinessDate 这类替换变量，然后在 Stored Procedure Transformation 的连接属性或参数值里引用。这样每个月跑批时只改参数文件，不用动 Mapping。
动态参数的坑在于变量替换发生在 Session 启动阶段，而不是运行到存储过程节点时才解析。也就是说，如果变量没有定义或赋值，Session 启动阶段就会报错，不会等到调用存储过程那一步。遇到这种错误，优先查参数文件有没有加载、变量名有没有写错。另一个坑是变量类型都是字符串，给 NUMBER 入参传值时隐式转换可能会丢精度，所以我通常在上游 Expression 里先做好类型转换再传参。
5. 高频故障排查：五个真实踩坑记录
5.1 现象：存储过程名提示“identifier not found”
存储过程就摆在数据库里，但 Informatica 一直提示找不到。后来发现 Oracle 里用双引号创建的对象名区分大小写，而 PowerCenter 导入时默认按大写解析。如果存储过程名是小写或在特殊 Schema 下，导入后名字对不上，执行时定位失败。
解决方法是先去数据库确认存储过程的实际名字和所属 Schema。可以在导入弹窗里手动补全 Schema 前缀，或者用同义词把过程名统一成大写别名。遇到这种问题，不要改 Informatica 端配置去适配，而是建议 DBA 把命名规范统一成大写加下划线，一劳永逸。
5.2 现象：Session 显示成功，目标数据没变化
这是最迷惑人的故障。Session log 整个流程都跑完了，目标表却一行都没动。查下来发现存储过程内部提交方式与 Informatica 的提交控制冲突：存储过程内部已经 COMMIT，但 Informatica 认为事务还没结束，Session 回滚时把数据库端的提交也一起回滚了。
解决方法是明确提交边界。存储过程内部不做 COMMIT，把提交交给 Informatica 的 Session 属性中的 Target Commit Interval 控制。如果存储过程必须自己提交，那就把 Session 的“Treat source rows as”改成 Pass Through，并关闭 Informatica 的目标事务管理，让数据库端自行控制。两种做法选定一种，不要两边同时提交。
5.3 现象：映射中用到的存储过程在测试库能跑，生产库不行
测试环境一切正常，上到生产就报错。核对后发现生产库账号没有存储过程的执行权限，或者存储过程依赖的临时表没有被授权。Informatica 报的错误往往是笼统的“Database driver error”，完全不提权限问题。
现在的做法是准备一份依赖检查清单，上线前在目标环境执行一次存储过程本身，确认能跑通再配 Informatica。同时让 DBA 在部署脚本里显式执行 GRANT EXECUTE ON 存储过程给 ETL 账号。权限这东西，一旦成为黑匣子，排查代价远大于事前检查。
5.4 现象：日期类型传参后存进库的数值错一天
存储过程入参是 DATE 类型，Informatica 端口定义为 String，结果传进去后日期错位或者变成 00:00:00。原因是没有显式做类型转换，Informatica 按字符传值，数据库端隐式转换时依赖会话级 NLS 参数。
解决办法是在传参前用 TO_DATE 函数显式转换，把日期字符串按固定格式转成 DATE。我知道有人图省事，直接在存储过程里 TO_CHAR 再 TO_DATE，但那只是把问题往后挪。ETL 端保证数据类型匹配，才不用依赖数据库会话参数。
5.5 现象：存储过程执行很慢，拖垮整个 Session
单个存储过程调用本身只要几秒，放到 Session 里就变成几十分钟。后来发现是逐行调用模式。默认情况下，映射从源读取一行就往目标存储过程发一次调用，网络往返加语法解析开销被放大。
解决方法是改成批量模式。在 Session 属性中设置“Target load type”为 Bulk，或者让存储过程接收集合类型参数批量处理。如果存储过程不支持批量，那就在 ETL 端做分组缓存，攒够一定行数再触发一次调用。这个优化做完，性能往往能有数量级提升。
6. 验证与进阶：从跑通到跑稳的一小步
先说验证。每次跑完 Session，不要只看“Completed”状态。我习惯从三个角度比对：Session Log 里的 Success Rows 数量是否与源表行数一致；目标表通过独立 SQL 统计数量是否与预期吻合；关键业务指标的汇总值和上游源表的计算结果是否在误差允许范围内。数据比对脚本往往比 ETL 本身还重要，宁可多花半小时做校验，也不要把错误数据留给下游。
进阶方向我推荐两个。一是把存储过程调用纳入异常重试机制，通过 Workflow 的 On Error 策略，把失败的任务自动重跑一至两次，同时把错误信息写入日志表。二是把存储过程调用封装成可复用的短作业，统一用参数文件驱动，这样不同业务线之间可以互换存储过程而不改动 Mapping。我见过太多项目把调用逻辑写在各个 Mapping 里，每次改动都要全局搜索，维护成本极高。
最后讲个教训：曾经有一次我把存储过程提交写得过于激进，Session 重启后目标表出现重复数据，而存储过程本身做了主键冲突回避，结果两边不一致。从那以后，我要求所有跑批作业必须支持“幂等重跑”，存储过程要么带批次号过滤，要么先清后写。这个习惯让后续很多次夜间重跑都没再出过岔子。里程碑式的进步往往不是跑通一次，而是每次都能安全地重新跑一遍。希望这个思路能帮你在处理 Informatica 和存储过程的协作时少走弯路。
本文还有配套的精品资源，点击获取
