企业官网建设流程全解析

简介：一份面向 Informatica 数据集成开发与 ETL 工程师的图文流程讲解，围绕在 Mapping 中调用存储过程这一高频需求展开。文档先说明存储过程的概念、批量执行与安全控制优势，再逐步演示新建 Mapping、右键目标表选择 Edit、在属性选项卡的 pre SQL 栏写入调用脚本、用变量替换入参等关键操作，并解释这些步骤背后的配置逻辑，最终保存运行即可完成调用，同时覆盖数据迁移、数据同步、报表生成等典型应用场景。资源以 1 个 docx 文档呈现，压缩包约 180KB，图文步骤清晰，便于对照操作。已有 976 人学习下载，适合需要快速掌握 Informatica 调用存储过程的初中级数据集成人员。通过这份图文说明，读者能获得从配置入口、脚本编写到运行验证的完整路径，以及参数传递与排错要点，有效减少试错成本。

1. 调用存储过程不用加控件：一条 pre SQL 就够

第一次在 Informatica 里要让目标表加载前先跑一段存储过程，我翻了半天组件面板，差点以为必须加某个专门的 Stored Procedure 控件，后来才发现最省事的路径一直藏在目标表属性里。这个图文流程解决的事情很具体：你在基于 Informatica 做数据迁移或数仓采集，希望在数据写进目标表之前，由数据库端的一段存储过程完成初始化、清理批次或参数校验，同时又不想为此改动 Mapping 的整体结构。整份笔记的核心动作就四步——新建 Mapping、右键目标表、在属性选项卡的 pre SQL 里写脚本、保存运行。适合刚接触 Informatica PowerCenter、正卡在“存储过程到底挂哪”的开发或运维同学，也适合想确认变量传参边界的老手。

2. pre SQL 在哪执行：目标表属性面板与加载时序

2.1 为什么调用要放在目标表的属性里

在 PowerCenter 的 Mapping 里，能写自定义 SQL 的地方不止一处，但存储过程调用的位置选错了，后面全是找补。我先给出结论式的判断：如果目的是“目标数据进来之前在目标库里跑一段逻辑”，就把存储过程调用写成目标表的 pre SQL，理由要从连接和时机两个维度看。

pre SQL 的执行连接是目标库连接，这意味着它可以直接操作目标表所在的库，也能调用这个库里的存储过程。而放在 Source Qualifier 那一侧，跑的是源连接，操作的往往是源库，调用的也只能是源库里的过程，和你“在写入端做准备”的目标完全是两码事。放在 Expression 里更别扭，因为 Expression 作用在行数据上，它面对的是每条记录的字段，表达不了库级调用。

时序上，pre SQL 发生在目标表加载动作之前。它的语义是“这一批数据进来之前，先在库里做点准备”，存储过程调用天然属于这种准备动作：清批次、删临时表、初始化日志、生成主键段，都是典型的 pre-load 逻辑。把它绑在目标表属性上，每次这个表被加载前都会自动执行，不需要额外引一条 Transformation 流程。

2.2 pre SQL 与 post SQL 的执行时序

打开目标表编辑框的属性选项卡，会看到两个多行文本框：Pre SQL 和 Post SQL。理解这两个框的关键是执行时机，这个时序不是黑匣子，PowerCenter 的 session 执行日志里都会留痕。

session 启动后，Integration Service 先建立目标连接，然后按顺序执行：源端抽取 → 目标表 pre SQL → 目标表加载 → 目标表 post SQL → 后续清理。pre SQL 发生在加载前，post SQL 发生在加载完成后。如果在 pre SQL 里做的是批量清理，加载失败时事务回滚还能把清理动作一并撤销；如果在 post SQL 里做汇总重算，前提是数据已经完整进去。

需要留意的是，pre SQL 不是 Mapping 级别的配置，而是表定义级别的配置。同一个目标表定义如果被多个 Mapping 引用，这段 SQL 会被每个使用它的 session 各自执行一遍。这不是 Bug，是把前置逻辑绑定到了表上。如果你某个 Mapping 不希望它执行，只能在 session 属性里做区分处理。

还有一个容易忽略的点：当目标表配置了分区加载或者启用了并行写目标，pre SQL 可能不只执行一遍。我一般建议在对话里先确认 session 是否对目标表拆了 partition，拆了就把 pre SQL 做成幂等操作，别把“插入一条日志”这种非幂等逻辑放进去，否则每个分区都会插一条。

2.3 三种数据库下的调用写法

不同数据库在 pre SQL 里调用存储过程的语法不一样。PowerCenter 的 pre SQL 管理器会把整个文本框内容作为一条语句交给数据库驱动，而不是像 SQL*Plus 那样逐行解释，所以某些客户端能用的简写在这里会翻车。

以最常见的目标库为例，Oracle 下推荐匿名块写法：

-- Oracle 目标库：匿名块调用存储过程，并一起提交 BEGIN sp_clean_batch('2024-11-20'); -- 清空/刷新业务日期对应的批次数据 COMMIT; -- 显式提交，防止挂在会话事务里 END;

SQL Server 目标库可以直接 EXEC：

-- SQL Server 目标库：EXEC 直接调用 EXEC sp_clean_batch '2024-11-20';

DB2 目标库用 CALL：

-- DB2 目标库：CALL 调用 CALL sp_clean_batch('2024-11-20')

说明一下为什么 Oracle 不写 EXEC：EXEC 在 SQL*Plus 里能用，但 PowerCenter 通过 JDBC 提交时，EXEC 不是标准可执行语句，经常被数据库直接拒掉，报 ORA-00900。匿名块的好处是整段被当成一个复合语句提交，结尾 END; 的分号必须带上。DB2 的 CALL 同样要保证语句完整，不要依赖客户端交互补全。如果你不确定连接对应的数据库版本，先把语句放到数据库客户端里跑一遍，再把同样文本粘进 pre SQL，这是最朴素也最有效的验证方式。

3. 完整操作流程：从新建 Mapping 到跑通第一次调用

3.1 新建 Mapping 与导入目标表定义

第一步按图文笔记里说的，在 Repository 导航器的目标文件夹上右键，选择 New → Mapping，打开 Mapping Designer。此时画布是空的，我们要做的是把目标表拖进来。

先确认目标表定义已经通过数据库连接导入到 Repository。右键画布空白处选 Add Tables，从弹出的树里找到目标库连接，展开后选中目标表确定。这一步很容易被做顺手的人忽略，却是后面所有操作的前提：如果你用 SQL 编辑器手搓了一张虚拟目标表，它的属性选项卡里 pre SQL 编辑框往往不可编辑，或者保存后根本不生效。

很多老手在这里会踩一个隐形的坑：从文件导入的表定义和从数据库反向生成的表定义，属性面板的完整度不一样。我习惯在导入后先双击表对象，看它的连接信息里有没有正确的数据库连接名和表名，确认表定义不是“游离”的。游离表定义往往只带列结构，没有绑定连接，pre SQL 写了等于没写。

3.2 右键目标表 Edit，进入属性选项卡

在画布上的目标表对象上右键，选择 Edit。注意是右键目标表对象，不是双击表头，也不是在 Mapping 空白处右键。弹出的对话框里能看到这个表定义的详细信息，包括列定义、键约束、连接信息等。切到属性选项卡，往下滚动就能看到 SQL 区域。

这里有两个多行输入框：Pre SQL 和 Post SQL。中英文版本的差异不大，PowerCenter 中文界面下仍然会显示为 Pre SQL 和 Post SQL，有些高版本会翻译成“预 SQL”“后 SQL”，认准时序语义就行。

第一次看到的人容易直接往 Pre SQL 里写一串以分号结尾的 SQL，忘了 Informatica 会在运行时对文本做变量解析。这里不需要研究它的解析器，只需要记住一个原则：写完整、能独立执行的语句，不要依赖任何客户端交互。比如有人在 pre SQL 里写“SET SERVEROUTPUT ON”这种会话指令，它根本不是可提交的语句，session 一跑就报错。

3.3 在 pre SQL 里写下调用脚本

假设存储过程是 sp_clean_batch，输入参数是业务日期，把它写进 Pre SQL 文本框：

-- 清理指定业务日期的批次表，然后提交 BEGIN sp_clean_batch('2024-11-20'); COMMIT; END;

这里有两个值得说明的细节。COMMIT 是显式提交，目的是避免存储过程执行后，事务长时间挂在连接上影响后续加载。另一个细节是入参类型：如果存储过程入参是 DATE，你传了一个字符串，隐式转换规则和连接参数不一致时，会在这一步直接报 ORA-01861，文本看起来是参数问题，根子其实是类型没对上。

写完先别急着保存，在数据库客户端里用同一连接账号跑一次这段脚本，确认权限、参数、提交语句都没问题。我在模拟项目 X 的迁移里遇到过多次“pre SQL 报错但直觉认为没问题”的情况，多数是参数类型不符。数据库客户端能跑通，基本能排掉低级的类型问题。

3.4 保存、建 Workflow、查看 Session Log

保存 Mapping 后，后面几步和正常 Mapping 处理没有任何区别。打开 Workflow Manager，新建 Workflow，把 Session 任务放进去，配置好源连接和目标连接，指定刚才保存的 Mapping，然后启动。

运行后最重要的动作是看 Session Log。Workflow Monitor 里右键对应 session，选择 Get Run Properties，再打开 Session Log，搜索关键字“Pre SQL”或直接搜存储过程名。正常的日志里能看到类似 Executing SQL 的记录，后面跟着的往往是变量替换之后的完整语句。这是唯一能确认“pre SQL 真的按照预期执行了”的地方。

如果日志里找不到存储过程名，先确认 session 用的 Mapping 是不是属性修改后保存的版本。多人协作时经常出现有人用旧版本 Mapping 覆盖了工作区，pre SQL 还在，但 session 引用的是另一个 Mapping 定义，这种问题看 log 比看界面快得多。

4. 参数动态化：变量替换与传参的写法

4.1 先分清 $$ 参数和 $ 变量的区别

pre SQL 里最常用的变量是 $$ 开头的 Session 参数。它与 $ 开头的 Workflow 变量是两套东西：$$ 参数在 Session 执行前由参数文件赋值，执行时做文本替换；$ 变量是 Workflow 运行时的内部变量，例如跟踪计数、上次运行时间等，在 pre SQL 文本里一般不做字符串替换。

我见过不少把 $ 开头的 Workflow 变量塞进 pre SQL 的写法，跑起来时好时坏，看着很玄学。其实不是玄学，是根本不在同一套解析体系里。pre SQL 的解析发生在 Integration Service 执行 session 的阶段，它认的是 session 参数和 mapping 参数，Workflow 变量的生命周期在更外层，不会渗透进这条 SQL 文本。

在项目实践中，凡是需要按批次传入的业务日期、批次号、源文件编号，我习惯统一用 $$ 参数。它的赋值入口非常清晰：参数文件里写好值，Session 配置里指定参数文件路径，Integration Service 在跑 Mapping 前把 $$ 占位符替换成实际值。用 $$ 还有一个好处是排错链路短，日志里直接能看到替换后的 SQL。

4.2 日期与批号参数的替换实操

假设存储过程需要两个入参：业务日期、批次编号。在 pre SQL 里这样写：

-- 两个入参都用 $$ 占位符，运行时替换 BEGIN sp_clean_batch('$$BizDate', '$$BatchId'); END;

参数文件里这样配：

# 段名必须与 Session 任务名完全一致 [s_m_test] $$BizDate=2024-11-20 $$BatchId=B20241120

说明一下，[s_m_test] 是 Session 任务名，段名必须和 Session 任务名完全一致，否则参数不会被读到。变量替换是纯文本替换，所以 SQL 里的单引号要自己包好。上面代码里，$$BizDate 前后有单引号，替换后数据库看到的是 '2024-11-20'；如果入参是数字，就不用加单引号，直接写 $$BatchId。

这里有个容易看晕的地方：参数文件里写不写单引号？我遇到的多数翻车都是参数文件里写了 '2024-11-20'，然后 pre SQL 里也写了 '$$BizDate'，替换后变成两个引号套在一起，数据库直接报语法错误。统一规则就一条：单引号永远留在 SQL 模板内，参数文件里只放裸值。

4.3 参数没被替换时优先检查哪里

新手最常见的翻车点是：workflow 配好了参数文件，但 pre SQL 里的变量原样出现在 Session Log 的 SQL 文本里。原因一般有三类：第一，参数文件段名和 Session 名不一致；第二，Session 的 Properties 里没有指定参数文件路径；第三，变量以 $ 开头，被当成了 Workflow 变量，而 pre SQL 不解析它。

我的一般排错顺序是：先看 Session Log 里有没有 Reading parameter file 之类的字样，确认参数文件确实被加载；再到 Session 任务属性里核对配置页签下的参数文件全路径；最后检查变量前缀。逐层往下，基本三轮能定位。

还有一个项目初期常用的做法：先保留一条带硬编码参数的 pre SQL 作为对照组，跑通一次，再改成变量跑第二次。这个过程能快速区分是存储过程本身的问题还是变量替换的问题，比直接改参数猜来猜去省时间。

5. 避坑：pre SQL 调用存储过程的五个常见问题

5.1 现象：Session 成功但存储过程没执行

这种情况最迷惑人。Workflow 显示成功、目标表数据也正常，但数据库里查不到存储过程的执行痕迹。原因通常是目标表的加载方式走了直接加载路径，或者 session 配置里对目标表启用了动态表名，导致 pre SQL 被跳过或没有落在“真正写入数据”的那个连接上。

解决：先确认目标表属性里的 pre SQL 确实保存了，再在 session 属性里看目标加载类型，如果选了直接加载，改成常规加载再试一次。判断标准不要用“Session 成功”，要用数据库里的日志或表的副作用作为依据。

5.2 现象：Oracle 一直报 ORA-00900

ORA-00900 的文本是 invalid SQL statement，看到它先别怀疑数据库。常见原因是 pre SQL 里直接写了 EXEC sp_clean_batch(...)，这个语法在 SQL*Plus 里能跑，但 PowerCenter 通过 JDBC 提交时，EXEC 不是标准语句。

解决：改成 BEGIN sp_clean_batch('2024-11-20'); END; 的匿名块，或者写成 CALL sp_clean_batch('2024-11-20')。我习惯匿名块，因为它能顺带把 COMMIT 写在同一段里，少一次连接往返。

5.3 现象：字符串参数被替换后 SQL 语法错

比如参数文件里配了 $$BizDate=2024-11-20，pre SQL 里写 sp_clean_batch($$BizDate)，替换后变成 sp_clean_batch(2024-11-20)，数据库把它当成数值减法处理，直接报错。单引号必须写在 SQL 模板里，而不是参数值里。

解决：统一规则——字符串入参在 pre SQL 里写 '$$Param'，单引号永远留在模板内；参数文件里只放裸值。如果参数值本身可能含有单引号，比如文本型备注，需要在参数文件里预先转义，或者在存储过程内部用参数化方式接收，不要依赖文本替换硬拼。

5.4 现象：存储过程执行了但又被回滚

session 中途失败时，pre SQL 已经执行完，最终目标表数据都没进来，存储过程的动作也不见了。原因在于 pre SQL 和目标表加载共用同一个事务连接，加载失败时事务回滚把存储过程也带回去了。

解决：如果存储过程不是必须和加载保持一致，在匿名块里显式加 COMMIT。反过来也要清楚：一旦 COMMIT，后面加载失败时存储过程不会回滚，这是取舍。我一般看业务语义决定——清批次表这种幂等操作可以提交；生成主键段这种强一致性操作不要提前提交，让 session 统一控制。

5.5 现象：变量名原样出现在 SQL 里

日志里能看到 $$BizDate 原样出现在提交给数据库的 SQL 文本中，说明文本替换没有发生。原因基本是参数文件没被加载，Session 配置里没指定参数文件、段名对不上、或者 Mapping 参数和 Session 参数重名，都可能造成这种现象。

解决：把变量定义收敛到 Session 参数，不要同时在 Mapping 里创建一个同名参数。预览阶段可以先用硬编码 SQL 验证链路通，再换成变量。逐层验证是排这类问题最省时间的办法，比反复重启 workflow 有效。

6. 进阶：post SQL 场景与验证存储过程真实执行

6.1 post SQL 的典型场景

pre SQL 之外，属性选项卡里的 post SQL 同样可以调用存储过程，只是时机换到了目标表加载完成后。当我需要在数据落库之后立刻触发汇总重算、更新批次状态或做跨表一致性校验时，会优先考虑 post SQL。把两者分开看：pre 做准备，post 做收尾。

6.2 验证存储过程真实执行的两个办法

第一个办法是 Session Log 搜关键字，看替换后的完整 SQL。第二个更可靠的办法是在存储过程里写一张操作日志表，每次调用插入一条带时间戳的记录。日志表对 ETL 任务尤其重要，下游调度可以直接查这张表判断前置步骤是否完成。如果不想改存储过程，也可以在数据库端临时开启 SQL 跟踪，但批量环境里开销较大，我一般只在排查问题时开。

6.3 我现在的固定习惯

每次把带 pre SQL 的 Mapping 提上去之前，我都会强制走一遍：数据库客户端执行同样的匿名块，跑一次空批次 session，在 Session Log 里搜存储过程名，在日志表里确认有记录。这套动作花不了五分钟，但能把“怎么办”类问题拦截在发布之前。从那以后，凡是涉及 pre SQL 的任务上线，我都默认走这条验证路径，省了很多半夜处理告警的事。希望帮到你。

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