企业官网建设流程全解析

简介：这份资源面向数据集成工程师与 Informatica 初学者，聚焦在 Informatica 工作流中调用数据库存储过程这一常见需求，帮助读者理解如何借助 pre SQL 机制在数据加载前执行存储过程脚本，并处理入参变量的替换问题。资源包内共 1 个 docx 文档，约 180KB，以图文结合的方式梳理了从新建 Mapping、编辑目标表属性、切换到属性选项卡写入 pre SQL，到保存并运行映射的完整流程，同时补充了存储过程的基本概念、使用优点以及数据迁移、数据同步、报表生成等典型应用场景。目前已有 976 人学习下载，适合需要快速上手 Informatica 存储过程调用、对照图文步骤完成配置与排错的数据集成从业者参考。

1. 别急着写 Pre SQL：先搞懂 Informatica 调用存储过程到底在调什么

很多人第一次在 Informatica 里调存储过程，都是被一句话带进坑的：“右键目标表，Pre SQL 里写脚本就行。”听起来简单，真跑起来却经常遇到权限报错、参数传不进去、事务回滚、日志里连存储过程名字都看不到。问题不在手速，在于没分清 Informatica 到底把这段 SQL 发给了谁、在哪个连接上执行、什么时候提交。

这份资源讲的是一套图文流程：新建 Mapping，右键目标表进入 Edit，切到属性选项卡，在 Pre SQL 里写调用脚本，有变量就把入参替换成变量，保存后运行。它解决的是 ETL 开发中最常见的一类需求——数据加载前后需要触发数据库侧的存储过程，比如清理临时表、汇总中间结果、写审计日志、调用业务封装逻辑。适合已经会建 Mapping、但对“Pre SQL / Post SQL 执行时机、参数绑定、事务边界”还模棱两可的 Informatica 开发人员。下面按我实际拆项目的顺序，把每一步为什么这么做、参数怎么设、哪里容易翻车讲透。

2. 调用位置选型：Pre SQL、Post SQL 与 Stored Procedure Transformation 的边界

2.1 三种调用方式分别适合什么场景

Informatica 里调存储过程，常见做法不止一种。资源里用的是目标表属性中的 Pre SQL，这是最轻量的方式，适合“加载前做一次数据库侧动作”的场景。但如果你把三种方式混着用，很容易出现执行顺序和事务上的玄学问题。

选型理由很直接：如果存储过程只是“跑一下、不需要返回值”，Pre SQL 或 Post SQL 最省事；如果存储过程有 OUT 参数、返回值要参与后续转换，或者需要按行调用，那就别硬塞进 Pre SQL，改用 Stored Procedure Transformation。资源里的流程属于前者，所以它把脚本写在目标表属性里，而不是拖一个 Transformation 进 Mapping。

提示：Pre SQL 在目标表加载前执行，但如果目标表加载失败，Pre SQL 已经执行的部分是否回滚，取决于数据库和 Informatica 的提交配置。别默认它会自动撤销。

2.2 新建 Mapping 与目标表 Edit 的实际操作路径

按资源流程，第一步是新建 Mapping。在 Designer 里从 Repository 连上目标数据库后，拖入 Source 和 Target，把字段连起来。这里有个容易被忽略的点：目标表必须已经导入到 Informatica 的 Target Designer 里，否则右键 Edit 时看不到完整的属性选项卡。

操作步骤可以拆成下面这样：

1. 打开 Designer，连接目标 Repository。
2. 新建 Mapping，命名建议带业务域和过程名，比如m_ord_sp_refresh。
3. 从 Source Analyzer 拖入源表，从 Target Designer 拖入目标表。
4. 用 Expression 或直接连线完成字段映射。
5. 在 Mapping 画布中右键目标表实例，选择 Edit。

进入 Edit 后，切换到属性选项卡。不同版本里这个选项卡可能叫 Properties，也可能在 Target 定义和 Instance 属性之间切换。资源里说的“属性选项卡”指的是目标表实例属性，不是 Target 定义本身的列属性。这一点如果搞混，Pre SQL 写进去也不会生效。

2.3 Pre SQL 脚本的写法与变量替换

在 Pre SQL 栏里写调用脚本，语法取决于目标数据库。以常见的关系型数据库为例，调用一个带两个入参的存储过程，脚本大致如下：

-- 目标表 Pre SQL 示例：调用存储过程，入参使用 Informatica 变量 CALL etl_pre_load(‘$$SRC_BATCH_ID’, ‘$$LOAD_DATE’);

如果是 SQL Server 风格，可能是：

-- SQL Server 风格调用 EXEC etl_pre_load @batch_id = ‘$$SRC_BATCH_ID’, @load_date = ‘$$LOAD_DATE’;

逻辑说明：Pre SQL 里的脚本会由 Informatica 在目标数据库连接上执行。$$SRC_BATCH_ID和$$LOAD_DATE是 Mapping 参数或系统变量，运行时被替换成实际值。参数说明：$$前缀是 Informatica 参数文件的变量引用方式，也可以在 Mapping 里定义参数后直接使用。如果存储过程需要字符串类型，记得在变量外层加单引号；如果是数字类型，不要加引号，否则数据库会做隐式转换，轻则索引失效，重则直接报类型错误。

保存 Mapping 后，按常规方式创建 Session、Workflow，运行即可。但运行前建议先在数据库客户端里手动执行一遍同样的调用语句，确认存储过程本身没问题，再把脚本贴进 Pre SQL。这样能把“数据库侧错误”和“Informatica 侧错误”分开排查。

3. 参数绑定与变量替换：把入参写对才能跑通

3.1 Mapping 参数、Session 参数与系统变量的优先级

Informatica 的变量体系分好几层：Mapping 参数、Session 参数、Workflow 变量、系统变量。Pre SQL 里能引用哪些，取决于变量在哪个层级定义。常见做法是：把批次号、加载日期这类每次运行都可能变的值定义成 Mapping 参数，在 Session 里赋值，Pre SQL 直接引用。

优先级上，Session 参数会覆盖 Mapping 参数，Workflow 变量又可能覆盖 Session 参数。如果发现 Pre SQL 里拿到的值不是预期值，先查参数文件里有没有重复定义。我一般会在 Session 日志里打开参数追踪，确认最终替换值。

-- 在 Pre SQL 中引用 Mapping 参数 CALL etl_pre_load(‘$$BATCH_ID’, ‘$$LOAD_DATE’);

参数说明：$$BATCH_ID需要在 Mapping 参数或 Session 参数中定义，类型为 string；$$LOAD_DATE可以用系统变量$$RUN_DATE替代，格式由数据库决定。如果存储过程要求日期格式为YYYY-MM-DD，而系统变量带时间戳，就要在 Expression 里先格式化，或者直接在 Pre SQL 里用数据库函数转换。

3.2 入参替换的三种常见写法与翻车点

第一种，直接写死值。适合测试，不适合生产。第二种，用 Informatica 变量替换。第三种，用数据库端的绑定变量。资源里说的是第二种，也是最容易出问题的一种。

翻车点一：变量名拼错。Informatica 不会在保存时校验 Pre SQL 里的变量是否存在，只有运行时才报“无法解析参数”。翻车点二：引号嵌套。如果变量值本身带单引号，直接拼进 SQL 会截断语句。翻车点三：变量类型与存储过程参数类型不匹配。比如存储过程要 integer，变量是 string，数据库可能隐式转换，也可能直接报错。

注意：Pre SQL 里不要写SELECT去调用存储过程，除非数据库支持这种语法。多数数据库要求用CALL或EXEC。

3.3 用 Session 日志验证参数是否传对

运行 Workflow 后，打开 Session 日志，搜索 Pre SQL 关键字。Informatica 通常会把最终执行的 SQL 语句打印出来，但不同版本日志级别不同。如果看不到，可以在 Session 属性里把日志级别调到 Verbose Data 或 Debug。

日志里重点看三件事：Pre SQL 是否在目标加载前执行、变量是否被替换成实际值、存储过程是否返回错误。如果日志里只有“Pre SQL executed successfully”但没有具体语句，就去数据库端查审计日志或开启数据库的 SQL 追踪。这一步是排查“存储过程没执行”或“执行了但没效果”的关键。

4. 避坑与排查：Pre SQL 调存储过程的五个血泪经验

4.1 现象：Pre SQL 写了但存储过程没执行

原因：最常见的是目标表实例属性没保存，或者 Pre SQL 写在了 Target 定义而不是 Instance 上。另一个原因是 Session 里目标表连接和 Pre SQL 执行连接不是同一个，脚本发到了错误的数据库。

解决：重新右键目标表实例，确认属性选项卡里的 Pre SQL 有内容；检查 Session 里目标表的连接对象；在数据库端开启 general log，确认有没有收到调用请求。

4.2 现象：报错“ORA-06550”或“PLS-00201”之类的权限错误

原因：Informatica 连接数据库使用的账号没有执行该存储过程的权限。存储过程可能属于另一个 schema，或者需要 EXECUTE 授权。

解决：让 DBA 给连接账号授予EXECUTE权限，或者把存储过程调用改成schema_name.procedure_name的全限定形式。如果是 SQL Server，还要确认账号有 EXECUTE AS 相关权限。

4.3 现象：存储过程执行了，但目标表加载失败后数据没回滚

原因：Pre SQL 和后续加载可能不在同一个事务里，或者数据库的 DDL 语句自动提交。存储过程内部如果有 COMMIT，也会导致回滚失效。

解决：把存储过程内部的 COMMIT 去掉，交给 Informatica 控制事务；或者在 Session 里调整提交策略，确认 Pre SQL 和目标加载的提交边界。如果业务允许，把清理逻辑改成 Post SQL，等加载成功后再执行。

4.4 现象：变量替换后 SQL 语法错误

原因：变量值带特殊字符、引号不匹配、日期格式不对。比如$$LOAD_DATE替换成2024-01-01 00:00:00，但存储过程参数是DATE类型，数据库可能不接受带时间的字符串。

解决：在 Pre SQL 里用数据库函数显式转换，比如TO_DATE(‘$$LOAD_DATE’, ‘YYYY-MM-DD’)；或者在 Mapping 里先用 Expression 把变量格式化好。字符串变量一定要加单引号，数字变量不要加。

4.5 现象：Pre SQL 执行时间过长，拖慢整个 Workflow

原因：存储过程里做了大批量数据处理，或者锁等待。Pre SQL 是在目标加载前同步执行的，它不结束，后面的加载就不会开始。

解决：把耗时逻辑拆到独立的 Session 里，用 Workflow 的链接条件控制顺序；或者在存储过程里加分批提交，避免长事务。如果只是写审计日志，考虑改成 Post SQL 或异步方式。

5. 进阶验证：用数据库端追踪和 Informatica 日志双向确认

5.1 在数据库端确认调用真的发生了

Informatica 日志说“执行成功”，不代表存储过程真的做了你想做的事。我一般会在数据库端开一个短时间的追踪，比如 MySQL 的 general log、Oracle 的 SQL trace、SQL Server 的 Extended Events。把 Pre SQL 里的调用语句和数据库端收到的语句对比，确认参数值、执行时间、执行账号都对得上。

如果数据库端根本没收到调用，问题就在 Informatica 侧：检查 Pre SQL 是否写在了正确的目标表实例上，Session 是否真的用了这个 Mapping，Workflow 是否跑到了那个 Session。

5.2 用存储过程内部的日志表做业务级验证

更可靠的做法是让存储过程自己写日志。在存储过程开头插入一条记录到日志表，记录批次号、参数值、开始时间；结尾再更新结束时间和影响行数。这样不管 Informatica 日志怎么显示，业务侧都有据可查。

-- 存储过程内部日志示例 INSERT INTO etl_proc_log(proc_name, batch_id, start_time) VALUES (‘etl_pre_load’, p_batch_id, SYSDATE);

参数说明：p_batch_id是存储过程入参，来自 Informatica 变量。日志表建议加索引在batch_id和start_time上，方便按批次查询。如果存储过程执行失败，日志表里至少会留下开始记录，能帮你判断是没调用还是调用后失败。

5.3 一个我常用的检查习惯

从那以后我每次在 Pre SQL 里调存储过程，都强制走一遍“三查”：查数据库端是否收到调用、查存储过程内部日志是否有记录、查 Informatica Session 日志里变量替换值是否正确。三查都过了，才认为这条链路是通的。希望帮到你。

本文还有配套的精品资源，点击获取