企业官网建设流程全解析

简介：面向Informatica数据集成初学者与开发人员的一份实操型图文资料，聚焦在Mapping中通过目标表pre SQL调用数据库存储过程这一常见需求，帮助读者理解入参变量替换、保存运行等关键环节，适合需要快速上手该功能的中初级ETL工程师参考。压缩包内共1个docx文档，约180KB，以图文结合方式组织内容，便于对照阅读与随查随用。目前已有977人学习下载，具备一定的实践参考基础。资料围绕新建Mapping、右键目标表进入Edit、切换属性选项卡、在pre SQL栏写入调用脚本、用变量替换入参、保存后运行等流程展开，并补充了存储过程在提升集成速度、安全性与数据一致性方面的价值，以及数据迁移、数据同步、报表生成等典型应用场景，可帮助读者建立从概念到落地的完整认知，减少自行摸索的时间成本。

1. 存储过程在 Informatica 里到底怎么跑起来

很多做数据集成的人第一次碰到「在 ETL 流程里调存储过程」这个需求，第一反应是去找一个叫 Stored Procedure Transformation 的组件，结果发现配置项一堆、参数绑定绕、调试还看不到中间结果。其实在 Informatica 里，调用存储过程最省事的一条路，是把调用语句直接写进目标表的 pre SQL 或 post SQL 属性里——不用拖组件、不用配端口，改一行脚本就能跑。这个思路特别适合那些「加载前先清临时表」「加载后触发汇总过程」「用过程做批量校验」的场景，对已经熟悉 Mapping 开发、但不想为一次过程调用再搭一套 Transformation 的从业者来说，落地成本几乎为零。下面就把这条图文流程拆开讲透，包括参数怎么传、变量怎么绑、哪些坑会让你跑完发现过程根本没执行。

2. 为什么选 pre SQL 而不是存储过程组件

2.1 两种调用方式的边界对比

Informatica 里调用存储过程，主流有两条路：一是用 Stored Procedure Transformation 组件，二是把调用语句写进目标表的 pre SQL / post SQL。前者功能全，支持输入输出参数、支持返回结果集、能在 Mapping 中间环节调用；后者轻量，只在目标表加载的前后各执行一次，适合「过程只负责副作用、不需要把结果再喂回下游」的场景。

选哪条，先看你的过程是干什么的。如果过程只是做数据清理、日志写入、状态更新这类「执行完就完事」的动作，pre SQL 完全够用，而且配置量小到可以忽略。如果过程要返回一个结果集、或者返回值要参与后续的表达式计算，那就得老老实实用 Transformation 组件，因为 pre SQL 拿不到返回值。

我一般的判断标准很简单：过程执行完，下游还需要它的返回值吗？不需要，就走 pre SQL；需要，就上组件。绝大多数「加载前清表」「加载后跑汇总」的需求，都属于前者。

2.2 pre SQL 的执行时机与事务关系

pre SQL 在目标表开始写入之前执行，post SQL 在目标表写入完成之后执行。这两个时机点决定了它们和主加载流程的事务边界：pre SQL 执行失败，整个会话直接失败，目标表不会被写入；post SQL 执行失败，目标表的数据已经落库，但会话状态是失败，需要人工介入判断是否回滚。

这里有个容易被忽略的细节：pre SQL 和主加载是不是在同一个事务里，取决于目标表的数据库类型和 Informatica 的提交策略。对多数关系型数据库，pre SQL 是单独提交的，也就是说过程里的 DML 一旦执行就生效，主加载失败也不会自动回滚它。所以如果你的过程里有「先删再插」的逻辑，务必在过程内部自己做好异常处理，别指望 ETL 会话失败能帮你兜底。

提示：pre SQL 里不要写COMMIT，Informatica 会自己管理提交，手动提交会打乱会话的事务节奏，轻则报错，重则数据半截。

3. 从建 Mapping 到写 pre SQL：完整操作链路

3.1 建 Mapping 与目标表定义

先在 Repository Manager 或 Developer 里新建一个 Mapping，源和目标按常规方式拖进来。目标表这块要注意：pre SQL 是挂在目标表定义上的，所以目标表必须是已经导入到 Mapping 里的一个 Target 实例，不能是「只读源」那种用法。

建好之后，源到目标的字段映射按业务填好，先别急着跑。这一步的产出是一个结构完整的 Mapping，目标表实例在画布上可见。如果目标表是新建的，记得在导入时把表结构刷对，字段类型和长度跟数据库保持一致，否则后面 pre SQL 里引用的变量可能因为类型不匹配被静默截断。

3.2 打开目标表属性并定位 pre SQL

在 Mapping 画布上右键目标表实例，选 Edit，弹出目标表定义窗口，切到属性选项卡。不同版本的界面措辞略有差异，但属性名基本固定：Pre SQL 和 Post SQL 两个多行文本框。把光标放进 Pre SQL 框里，这里就是写调用语句的地方。

这个框支持多行，也支持多条语句用分号分隔，但我不建议在一个框里塞太多逻辑——过程调用一条就够，多了排查起来费劲。写之前先确认目标表的数据库连接是哪个，因为 pre SQL 是发给目标数据库执行的，语法必须匹配那个库的过程调用规范。

3.3 写入调用脚本与变量替换

最朴素的写法就是直接拼一条调用语句。以常见的数据库过程调用语法为例：

-- 目标表 pre SQL：调用清理过程，传入会话参数 CALL sp_clean_stage_table('${SESSION_NAME}', '${WORKFLOW_NAME}');

这段脚本在目标表加载前执行，把当前会话名和工作流名传给过程，过程内部据此清理对应的临时数据。${SESSION_NAME}和${WORKFLOW_NAME}是 Informatica 的内置会话变量，运行时会被替换成实际值。

如果过程需要业务参数，比如一个批次号，就用 Mapping 参数或会话参数来传：

-- 用 Mapping 参数传批次号，参数在会话里赋值 CALL sp_load_batch('${BATCH_ID}', SYSDATE);

参数说明：BATCH_ID是在 Mapping 里定义的参数，类型设为 string，在会话属性里给它赋值；SYSDATE是数据库函数，由目标库自己解析。注意变量替换发生在 SQL 发送之前，是纯字符串替换，所以字符串参数要自己带引号，数字参数不要带引号，否则过程收到的是字符串类型，可能报类型不匹配。

3.4 保存、运行与会话日志验证

保存 Mapping，然后按常规流程建会话、建工作流、启动。跑完之后别只看会话成功与否，一定要打开会话日志，搜 pre SQL 那一段，确认语句真的发出去了、过程真的执行了。日志里会打印实际执行的 SQL 文本，变量替换后的值也在里面，这是验证参数传对没传对的第一手证据。

如果过程内部有日志表，跑完顺手查一下日志表，确认过程被调用了几次、入参是什么。这一步是很多人的盲区——会话显示成功，但过程因为条件不满足直接 return 了，等于白跑。

4. 参数绑定与变量替换的四个实操细节

4.1 内置变量与自定义参数的取值来源

Informatica 的变量分几层：系统变量（如${SESSION_NAME}）、工作流变量、会话参数、Mapping 参数。pre SQL 里能引用的是运行时已经确定值的那些。取值优先级上，会话参数会覆盖 Mapping 参数的默认值，所以调试阶段我习惯把关键参数在会话里显式赋值，避免默认值把你带偏。

自定义参数在 Mapping 里定义后，要在会话的属性页里逐个赋值，漏赋一个，运行时就是空字符串替换进去，SQL 直接语法错误。这个错误在日志里表现为「ORA-00936 缺失表达式」之类的报错，看到这类错先回去查参数赋值表。

4.2 字符串、日期、数字三类参数的拼接口径

字符串参数必须自带单引号，日期参数要么用数据库的TO_DATE包一层，要么直接传数据库能识别的字面量，数字参数绝对不能带引号。这三条是硬规矩，违反任何一条，轻则过程收到错误类型，重则 SQL 注入式的语法崩掉。

-- 三类参数的正确拼法 CALL sp_process_data( '${STRING_PARAM}', -- 字符串：带引号 TO_DATE('${DATE_PARAM}','YYYY-MM-DD'),-- 日期：显式转换 ${NUM_PARAM} -- 数字：不带引号 );

参数说明：STRING_PARAM在会话里赋值为纯文本，不带引号；DATE_PARAM赋值为2024-01-15这种格式，由TO_DATE负责解析；NUM_PARAM赋值为纯数字。日期格式串要和会话里赋值的格式严格一致，差一个字符就是转换失败。

4.3 参数为空时的兜底写法

参数没赋值时替换成空串，这是最常见的翻车点。稳妥的做法是在过程调用外层加一层判断，或者用数据库的NVL/COALESCE给默认值：

-- 参数为空时给默认值，避免过程收到空串 CALL sp_load_batch( NVL('${BATCH_ID}', 'DEFAULT_BATCH'), SYSDATE );

这样即使会话里漏配BATCH_ID，过程也能拿到一个合法值继续跑，而不是直接崩在语法上。当然这只是兜底，参数该配还得配。

4.4 多条语句的执行顺序控制

pre SQL 框里写多条语句时，执行顺序就是书写顺序，但每条语句是否独立提交取决于数据库。如果第二条依赖第一条的结果，务必确认第一条已经提交可见。跨语句依赖在 pre SQL 里属于高风险写法，我的建议是能合并进一个存储过程就合并，让过程内部去控制顺序和事务，pre SQL 只留一条调用语句。

5. 避坑：pre SQL 调过程的五类常见故障

5.1 会话成功但过程没执行

现象：会话日志显示成功，目标表数据也加载了，但过程该写的日志表一条没有。原因通常是 pre SQL 框里写的是注释、或者语句被数据库当成无效语句静默跳过，也可能是过程内部第一行就RETURN了。解决：打开会话日志搜实际执行的 SQL 文本，确认语句非空且语法正确；再查过程内部逻辑，看入口条件是否满足。

5.2 变量替换后 SQL 语法错误

现象：会话失败，日志报「缺失表达式」「无效字符」之类。原因基本是参数类型和引号不匹配——字符串没带引号、数字带了引号、日期格式串对不上。解决：把日志里替换后的 SQL 文本复制出来，在数据库客户端里手动跑一遍，报错位置一目了然。

5.3 过程执行了但数据没生效

现象：日志显示 pre SQL 执行成功，过程日志也有记录，但目标表里看不到过程写入的数据。原因多半是事务没提交——过程内部做了 DML 但没COMMIT，而 pre SQL 的执行连接和主加载不是同一个事务，过程那边的改动在会话结束后被回滚。解决：在过程内部显式提交，或者确认数据库的自动提交设置。

5.4 权限不足导致过程调用失败

现象：手动在客户端能调通，Informatica 里跑就报权限错误。原因是 ETL 连接使用的数据库账号没有该过程的执行权限，或者没有过程内部访问的表的权限。解决：用 ETL 连接账号在客户端手动执行一次调用语句，复现权限问题，然后让 DBA 补授权。

5.5 post SQL 失败导致数据半落库

现象：目标表数据已经写入，但会话状态失败，post SQL 报错。原因是 post SQL 在数据加载后执行，此时数据已提交，post SQL 失败不会自动回滚主数据。解决：把 post SQL 里的逻辑做成幂等，失败后可以单独重跑；或者在过程内部做好异常捕获，别让 post SQL 抛错。

6. 进阶：把过程调用做成可复用模板

跑通一次不难，难的是让这条调用链路在几十个 Mapping 里保持一致、可维护。我的做法是把过程调用抽成一套参数化模板：pre SQL 里只写一条CALL，所有可变部分全部走 Mapping 参数，参数命名统一加前缀（比如P_PROC_），会话里按命名规则批量赋值。

-- 统一模板：过程名和参数全部参数化 CALL ${P_PROC_NAME}( '${P_PROC_ARG1}', ${P_PROC_ARG2}, TO_DATE('${P_PROC_ARG3}','YYYY-MM-DD') );

参数说明：P_PROC_NAME是过程名参数，会话里赋值为具体过程；P_PROC_ARG1到P_PROC_ARG3分别对应字符串、数字、日期三类入参。这样一套模板可以覆盖多个过程调用，改过程只改会话参数，不动 Mapping。

验证方法上，我习惯在过程内部加一张调用日志表，记录调用时间、会话名、入参值、执行结果。每次上线新 Mapping，跑完先查这张日志表，确认调用次数和入参都对，再看目标数据。这套「日志表 + 会话日志」双验证，比单看会话成功状态靠谱得多。

还有一个技巧：把 pre SQL 的调用语句在数据库客户端里存成一段可执行脚本，每次改完参数先在客户端跑一遍，确认语法和权限没问题，再贴回 Informatica。这一步多花两分钟，能省掉后面半小时的会话排查。

从那以后我每次配 pre SQL 调过程，都强制走一遍「客户端先跑通、日志表先建好、参数先显式赋值」这三步，再启动会话。希望帮到你。

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