简介：这份资源面向数据集成工程师与 Informatica 初学者，聚焦在 ETL 流程中如何通过存储过程完成数据加工这一常见需求，帮助读者理解在 Mapping 中调用数据库存储过程的完整图文流程。资源包共 1 个 docx 文档，约 180KB，以图文并茂的方式呈现关键操作界面与配置要点，便于对照实践。文档围绕新建 Mapping、编辑目标表属性、在 pre SQL 中写入调用脚本、使用变量传递入参以及保存运行等环节展开，并补充了存储过程的基本概念、调用优势与典型应用场景，如数据迁移、数据同步和报表生成。目前已有 976 人学习，适合需要快速掌握 Informatica 调用存储过程配置思路、排查参数传递问题的读者参考。
1. 为什么我劝你先别急着写 pre SQL：Informatica 调用存储过程的真实落地场景
很多人第一次在 Informatica 里调存储过程，都是被业务方一句“把这段逻辑封装成过程，ETL 直接调”推着走的。结果打开 Mapping，右键目标表，切到属性页，在 Pre SQL 里敲了一行exec proc_xxx，保存运行，报错。然后开始怀疑人生：是权限问题？是驱动问题？还是 Informatica 根本不支持？
其实 Informatica 调用存储过程这件事本身不复杂，复杂的是“在哪调、怎么传参、什么时候执行、失败了怎么查”。这篇笔记就围绕一个最小可复现的 Mapping，把 Pre SQL 调存储过程的完整链路拆开讲清楚。适合已经会用 Informatica 做基础抽数、但对存储过程集成还停留在“知道能调、没真正跑通”阶段的同学。如果你正在做数据迁移、批量同步或者报表预计算，这套流程能直接抄。
2. Informatica 调用存储过程的两种落点：Pre SQL 与 Post SQL 怎么选
2.1 先搞清楚存储过程在 ETL 链路里的位置
存储过程本质上是一组预编译在数据库端的 SQL 语句集合，它可以接收入参、执行插入更新删除、返回结果集或者输出参数。Informatica 作为数据集成工具，本身不解析存储过程内部逻辑，它只负责在合适的时机把调用语句发给数据库执行。
这就引出一个关键问题：什么叫“合适的时机”。在 Informatica 的 Mapping 里，目标表（Target）可以配置两类 SQL：
- Pre SQL：在数据加载之前执行
- Post SQL：在数据加载完成之后执行
如果你调用的存储过程是用来做数据清洗、预聚合、临时表构建，那应该放在 Pre SQL；如果是用来做加载后的汇总、状态回写、日志记录，那就放 Post SQL。原文只提了 Pre SQL，但实际项目里 Post SQL 同样常用，选错位置会导致数据顺序错乱。
我一般会先问自己三个问题：这个存储过程依赖目标表里已有的数据吗？它产生的数据会被本次加载用到吗？它失败了我希望整个 Session 回滚吗？三个问题的答案基本就能定位到 Pre 还是 Post。
2.2 新建 Mapping 与目标表属性入口
先建一个最小 Mapping：一个 Source 抽几条数据，一个 Target 指向目标表。Source 和 Target 之间可以不做任何转换，甚至 Source 可以直接用一个常量表达式，目的只是让 Session 有东西可跑。
建好之后，在 Mapping 画布上右键目标表实例，选择 Edit，进入目标表定义编辑界面。这里注意：你右键的是 Mapping 里的 Target 实例，不是 Repository 里的表定义。两者入口不同，改错了地方不会生效。
进入编辑界面后，切换到属性（Properties）选项卡。不同版本的 Informatica PowerCenter 界面略有差异，但属性页里一定会有 Pre SQL 和 Post SQL 两个输入框。如果找不到，检查一下是不是打开成了 Source 的属性，或者当前 Target 连接类型不支持 SQL 覆盖。
2.3 Pre SQL 里写调用语句的格式与变量替换
在 Pre SQL 框里写调用语句，格式取决于目标数据库类型。常见写法：
-- SQL Server 风格 EXEC dbo.usp_load_dim_customer @batch_date = '$$BATCH_DATE'; -- Oracle 风格 BEGIN pkg_etl.load_dim_customer(TO_DATE('$$BATCH_DATE','YYYY-MM-DD')); END; -- MySQL 风格 CALL sp_load_dim_customer('$$BATCH_DATE');这里$$BATCH_DATE是 Informatica 的 Mapping 参数或 Session 参数。在 Pre SQL 里可以直接引用，运行时会替换成实际值。如果存储过程有多个入参，就按数据库要求的顺序和命名方式逐个替换。
参数定义的位置在 Mapping 的 Parameters and Variables 里，或者 Session 的 Parameters 文件里。我一般把日期、批次号这类每次运行都可能变的值做成 Session 参数，把固定配置做成 Mapping 参数。这样同一个 Mapping 可以在不同 Session 里复用。
写完保存，然后像普通 Session 一样创建 Workflow、运行。如果存储过程执行成功，Session 日志里会看到 Pre SQL 执行的记录；如果失败，Session 会在加载数据之前就报错退出。
3. 参数传递与执行顺序：把变量、连接和 Session 日志串起来
3.1 Mapping 参数与 Session 参数的优先级
Informatica 的参数体系分三层：Mapping 参数、Session 参数、Workflow 参数。同名参数时，Session 参数会覆盖 Mapping 参数。这个优先级如果搞混，会出现“我明明改了参数值，运行结果还是旧的”这种玄学问题。
具体操作：在 Mapping 里定义$$BATCH_DATE，默认值写1900-01-01；在 Session 的 Properties 里找到 Parameters 部分，把$$BATCH_DATE覆盖成实际日期。运行时以 Session 的值为准。
如果你用的是参数文件（Parameter File），格式如下：
[FolderName.WorkflowName.SessionName] $$BATCH_DATE=2025-06-01 $$BATCH_ID=1001参数文件的好处是可以按批次生成，不用每次改 Session 属性。我一般会在 Workflow 里加一个 Command Task，先跑脚本生成参数文件，再跑 Session。
3.2 目标表连接与数据库权限确认
Pre SQL 是通过目标表的数据库连接执行的，所以这个连接对应的数据库账号必须有执行该存储过程的权限。常见坑是：开发环境用高权限账号跑通了，生产环境换了一个只读账号，直接报权限不足。
确认方法很简单：用目标连接对应的账号，在数据库客户端里手动执行一次调用语句。如果手动能跑通，Informatica 里基本也能跑通；如果手动都跑不通，先解决数据库侧问题。
另外注意连接类型。Informatica 支持的关系型目标连接有 Oracle、SQL Server、DB2、MySQL 等，不同连接类型的 Pre SQL 语法略有差异。比如 Oracle 的匿名块需要BEGIN ... END;，SQL Server 直接EXEC就行。
3.3 Session 日志里看什么：执行顺序与报错定位
运行 Session 后，日志里会按顺序记录：Session 启动、Pre SQL 执行、数据加载、Post SQL 执行、Session 结束。如果 Pre SQL 失败，日志里会显示类似PRE-SESSION SQL FAILED或者TM_6700之类的错误码。
我一般会重点看三个地方：一是 Pre SQL 实际执行的语句是什么，确认变量替换后的值对不对；二是数据库返回的错误信息，比如“对象不存在”“权限不足”“参数个数不匹配”；三是 Session 是否在 Pre SQL 失败后直接终止，还是继续跑了数据加载。
如果日志里看不到具体 SQL，可以在 Session 属性里把Override Tracing打开，或者查数据库端的审计日志。有些数据库会把存储过程调用记录在v$sql或者慢查询日志里，配合排查很有效。
4. 避坑与排查：Pre SQL 调存储过程最常见的五类翻车
4.1 现象：Session 报“无效的 SQL 语句”，但手动执行正常
原因通常是 Pre SQL 框里写了多条语句，或者语句末尾带了分号。Informatica 在发送 Pre SQL 时，有些连接类型不支持一次发送多条语句，也不支持末尾分号。
解决：把多条语句合并成一个存储过程调用，或者拆成多个 Pre SQL 条目（如果连接支持）。末尾分号去掉，Oracle 匿名块除外。
4.2 现象：变量没有被替换，存储过程收到的是字面量$$BATCH_DATE
原因一般是参数没有在 Session 或参数文件里赋值，或者参数名拼写不一致。Informatica 对参数名大小写敏感，$$BATCH_DATE和$$batch_date是两个不同的参数。
解决：在 Session 日志里搜索参数名，看是否有Parameter not found的警告。确认 Mapping 参数和 Session 参数名称完全一致，包括大小写。
4.3 现象：存储过程执行了，但数据没进目标表
原因可能是存储过程内部用了事务控制，比如COMMIT或ROLLBACK，而 Informatica 自己也在管理事务。两者冲突时，可能出现存储过程提交了但 Informatica 回滚了，或者反过来。
解决：确认存储过程内部是否有显式事务控制。如果有，评估是否与 Informatica 的提交策略冲突。常见做法是把存储过程改成不提交，由 Informatica 统一控制；或者把调用放到 Post SQL，让数据先加载完再执行。
4.4 现象：生产环境跑得慢，开发环境很快
原因通常是生产数据量大，存储过程内部缺少索引或者统计信息过期。也可能是 Pre SQL 在数据加载前执行，锁住了目标表，导致后续加载等待。
解决：在数据库端看执行计划，确认存储过程内部的查询是否走了索引。如果是锁等待，考虑把存储过程改成 Post SQL，或者调整 Session 的提交间隔。
4.5 现象：存储过程有输出参数，Informatica 拿不到返回值
原因：Pre SQL 和 Post SQL 本质上是“执行一条语句”，不负责接收输出参数。Informatica 没有原生的存储过程输出参数接收机制，除非用 Java Transformation 或者外部过程调用。
解决：如果业务逻辑依赖输出参数，常见做法是把输出参数写入一张日志表，然后在 Post SQL 里查这张表；或者改用 Informatica 的 Stored Procedure Transformation，它支持输入输出参数映射。
5. 进阶：用 Stored Procedure Transformation 替代 Pre SQL 的时机与验证方法
Pre SQL 调存储过程适合“执行完就行、不需要返回值”的场景。一旦你需要接收输出参数、需要根据返回值决定后续流程、或者需要在 Mapping 内部多次调用，Pre SQL 就不够用了。这时候应该考虑 Stored Procedure Transformation。
Stored Procedure Transformation 是 Informatica 提供的一个转换组件，它可以连接数据库、调用存储过程、映射输入输出参数。配置步骤大致是：在 Mapping 里拖入 Stored Procedure Transformation，选择数据库连接，选择存储过程，然后把输入端口和输出端口与上下游连接起来。
验证方法我一般分三步走：
| 验证项 | 操作 | 预期结果 |
|---|---|---|
| 数据库侧 | 手动执行存储过程 | 返回预期结果或输出参数 |
| Informatica 侧 | 运行 Session，看日志 | 无报错，输出端口有值 |
| 数据侧 | 查目标表或日志表 | 数据与预期一致 |
如果 Stored Procedure Transformation 报错，先看连接是否和 Pre SQL 用的是同一个。有些环境里 Pre SQL 走的是目标连接，Stored Procedure Transformation 走的是单独的存储过程连接，两者权限可能不同。
还有一个细节：Stored Procedure Transformation 的调用时机可以配置为“Once”或者“Per Row”。Once 表示整个 Session 只调一次，Per Row 表示每行数据调一次。选错了会导致性能问题或者逻辑错误。我一般默认用 Once，除非业务明确要求逐行处理。
从那以后我每次配 Pre SQL 调存储过程，都会先在数据库客户端手动跑一遍，确认权限和语法没问题，再进 Informatica 配参数。跑完第一遍 Session 后，一定去数据库端查一下存储过程有没有留下执行日志，确认它真的被调用了，而不是被 Informatica 静默跳过。这个习惯帮我省了很多次“以为跑了其实没跑”的后悔药。希望帮到你。
本文还有配套的精品资源，点击获取
