简介面向使用 Informatica 进行数据集成的开发与运维人员这份图文流程文档聚焦「调用存储过程」这一常见需求帮助读者理解在 Mapping 中通过目标表属性 pre SQL 写入调用脚本、结合变量传参并保存运行的整体做法适合需要快速上手或查阅操作细节的初中级使用者。压缩包仅含 1 个 docx 文件约 180KB篇幅集中、便于随查随用主要内容围绕操作路径与关键设置展开可作为日常实施时的参考笔记。目前已有 977 人学习说明该主题在实际项目中有一定关注度。文档以步骤化图文呈现能帮助读者梳理调用存储过程的配置位置、变量替换思路与运行前检查点对参数准备、脚本写法和执行顺序形成较清晰的认识减少在映射配置和 SQL 脚本编写上的试错也便于团队内部做知识传递与流程对齐。1. Informatica 调用存储过程五步能跑通翻车都在五步之外Informatica 调用存储过程这件事流程本身短得有点意外新建 Mapping对着目标表右键 Edit切到属性页在 Pre SQL 那一栏把调用语句贴进去保存、跑会话就结束了。真放到生产上跑出问题的地方几乎都集中在这五步之外——脚本什么时候执行、参数怎么替换、失败以后数据停在哪。这三点想不清楚测试环境一切正常上线当天就可能出现存储过程被调了两次、暂存表被清空、目标表只写了一半。下面的步骤按照我实际复现时的顺序排列每一步都标注了该在哪里停下来验证方便你照着做也能提前知道哪里容易出问题。2. pre SQL 的调用点与时序目标表属性里那一栏到底什么时候执行2.1 目标定义的 Pre SQL 卡在加载前Post SQL 卡在加载后Informatica 里能“执行一段 SQL”的位置至少有五处源限定符的 SQL Override、目标定义的 Pre SQL 与 Post SQL、会话级的 Pre SQL 与 Post SQL、工作流里的 Command Task。这五处的执行时间点、走哪条数据库连接、失败后数据处于什么状态全都不一样。调用存储过程之所以看起来简单、实际很容易出问题很大一部分原因就是挂载点选错了。目标定义上的 Pre SQL它的语义要拆成三个限定条件来看同一个目标连接、该目标被写入之前、本次会话中。这三个限定条件分别决定了三件事——权限必须落在 ETL 的连接用户上而不是 DBA 或者某个开发账号存储过程操作的对象必须是目标库里的对象跨库访问要么走数据库链接要么走全局同义词这两条路各有各的权限问题执行次数跟目标实例的数量绑定跟数据行数没有关系。执行次数这一条值得单独展开讲。很多人默认 Pre SQL 是“每批执行一次”实际是“每个目标实例打开前执行一次”。当目标没有分区、会话也没有配置并发时它确实只跑一次所以在测试环境里看不出问题。一旦目标做了分区或者会话被拆成多个并发实例往同一个目标写它就可能被执行多次。如果存储过程的逻辑是“清空暂存表再灌数据”第二次执行会把第一次灌进去的东西清掉最后写入目标表的数据是残缺的。这类问题在数据量小的环境里根本复现不出来只有接近生产的数据量加上分区配置才会暴露出来这也是它容易被当成玄学问题的原因。Post SQL 的问题在于失败代价不对称。它执行的时候目标数据已经写进去了提没提交取决于会话的提交间隔设置。存储过程在这一步抛错会话会失败但目标表里已经留下了一部分数据并停留在中间状态下游如果直接读这张表读到的是不完整的结果。所以凡是影响后续加载正确性的动作——建临时表、清暂存表、刷维度快照——都应该放在 Pre SQL让它在数据写入目标表之前失败宁可什么都没写也不要写入半截。源限定符的 SQL Override 也能调存储过程但它挂在源连接上。如果存储过程是往目标侧的暂存表写数据源连接根本够不到那张表除非做跨库访问那就又多出一层网络和权限问题。这条路线只在一种场景下合理存储过程本来就是在源库里做准备比如生成一个快照表供下游抽取。除此之外不建议挂在这里。会话级的 Pre SQL 是另一个选项它在会话真正开始处理数据之前执行跟目标有没有被打开无关。对于“即使源为空也必须跑一次”的准备工作这个位置比目标 Pre SQL 更可靠。代价是它拿不到目标表的上下文参数也少一层。挂载点执行时机执行次数失败后的数据状态适合放什么目标定义 Pre SQL该目标被写入前每个目标实例一次目标无新数据依赖目标库、必须在加载前完成的准备目标定义 Post SQL该目标写入后每个目标实例一次目标已有数据可能未提交收尾统计、状态回写、通知源限定符 SQL Override抽取阶段每次抽取无源库侧的预处理、快照生成会话级 Pre SQL会话开始、处理数据前每会话一次无源空也要跑的准备工作工作流 Command Task工作流任意节点由编排决定无跨库调用、需要独立失败重试的动作2.2 从空 Mapping 到跑通五个动作拆解先把最小可运行单元搭出来后面所有讨论都基于这个骨架。整个过程不需要任何复杂的转换组件单纯的源到目标直连就够验证调用链是否通。第一步建源定义和目标定义。做法是从数据库导入表结构选中源表和目标表把字段类型、精度、可空性一起导进来。这一步容易被跳过但字段精度不对会在写入阶段报截断错误和存储过程完全无关排查时容易误判。第二步新建 Mapping把源字段拖到目标字段上源和目标之间不要加任何转换组件。目的是先隔离变量只有数据流最简单的时候出问题才能确定是 Pre SQL 引起的。第三步右键目标表选择 Edit切到属性选项卡找到 Pre SQL 那一栏把调用语句贴进去。这里贴的是“调用语句本身”不是一整个脚本文件也不是带BEGIN/END的完整代码块具体形态取决于目标库支持哪种调用语法。-- 形态一无入参、无返回值最省事也最容易验证链路是否打通 CALL P_ETL_PREPARE_DIM();这段语句在目标被写入之前执行不返回结果集执行成功就继续抛错就让会话失败。P_ETL_PREPARE_DIM是存储过程名括号不能省部分数据库对无参过程也要求带括号。-- 形态二带位置入参值由会话参数在运行时替换 CALL P_ETL_STAGE_DIM($$v_batch_date, $$v_src_sys);$$前缀是 Informatica 的参数替换标记运行时会把$$v_batch_date整个替换成参数文件里配置的值。注意单引号写在语句里不要写在参数值里否则替换完会变成两对单引号直接语法错误。这一点在第三章还会再说一次因为它是最常见的失败原因之一。-- 形态三字符串字面量直接写死适合一次性验证 CALL P_ETL_STAGE_DIM(2024-06-01, CRM);写死字面量只用于验证链路验证完立刻改成参数形式。留在生产配置里的硬编码日期是后面所有“为什么每天都加载同一批数据”的源头。第四步生成 Session。在 Mapping 上右键生成会话或者在工作流里拖一个 Session 任务再关联 Mapping。连接对象要分别指定源连接和目标连接两边可以是同一个库也可以是不同的库。提交间隔保持默认值先不动等链路验证通了再调。第五步建工作流并运行跑完看会话日志。日志里搜PRE SQL或者存储过程名能看到实际下发的语句文本。如果日志里没有这一段说明 Pre SQL 根本没被执行先别怀疑语法去看目标有没有被打开。2.3 语句结尾的分号、换行与注释三个细节决定成败在 Pre SQL 输入框里写语句有三个细节跟直接连数据库客户端敲命令不一样踩过一次就记住了。分号的问题出在方言差异上。有些库的CALL语句末尾带分号会报语法错误因为驱动把分号当成了语句分隔符而匿名块形式又必须带分号否则块没闭合。判断方法很简单先在目标库的客户端里把同一条语句跑通客户端里怎么写的Pre SQL 里就怎么抄不要自己加也不要自己删。换行的问题更隐蔽。Pre SQL 输入框支持多行但部分版本在把文本下发到数据库之前会把换行折叠成空格。如果你的语句里有--行注释折叠之后整行后面的内容都会被当成注释吞掉报出来的错误位置跟你看到的完全对不上。稳妥做法是不在 Pre SQL 里写行注释需要说明就写在 Mapping 的描述字段里那个字段不会被下发。多语句的问题要看驱动。有的数据库连接允许一次发送多条用分号隔开的语句有的只认第一条。想在一个 Pre SQL 里既写审计记录又调存储过程能不能成得先试试不通就拆成两次执行或者把审计逻辑挪进存储过程内部。3. 入参与参数文件把硬编码的调用改成可复用模板3.1 三层传参Mapping 参数、会话参数、端口变量Informatica 里能当“参数”用的东西有三层作用域完全不同混用是参数替换失败的主要原因。Mapping 参数在 Mapping 级别定义前缀是$$作用域覆盖整个 Mapping包括源限定符 SQL、目标 Pre SQL 和 Post SQL、以及各转换组件的表达式。它的值可以在会话里覆盖也可以由参数文件提供。会话参数在 Session 属性里定义同样带$$前缀作用域是单个会话。它比 Mapping 参数更适合放“每次运行可能不一样”的东西比如批次日期、源系统标识。端口变量是转换组件上的字段跟着数据流一行一行走。它看起来最灵活但 Pre SQL 里引用不到。原因是 Pre SQL 在目标打开前就已经下发了那时候一行数据都还没进来端口上根本没有值。这一点绕不过去想“把某一行的 ID 传进存储过程”只能改用存储过程转换组件或者把处理粒度改成批级别。参数类型定义位置生效范围能否在 Pre SQL 里用Mapping 参数Mapping 的 Parameters and Variables整个 Mapping能前缀$$会话参数Session 属性页单个会话能前缀$$端口变量转换组件端口数据流内不能参数文件条目独立文本文件由工作流指定的会话能会覆盖同名参数把这张表记住能省掉一大半“为什么参数没替换”的排查时间。判断顺序是先看 Pre SQL 里用的是不是$$前缀再看这个参数在会话里有没有定义最后看参数文件有没有把它覆盖成空值。3.2 三种拼接写法与引号转义参数拼进 SQL 文本这个过程本质是字符串替换不是变量绑定。理解这一点引号问题就通了。第一种写法参数只作为值出现引号留在语句里。-- 正确引号在语句里参数值本身不带引号 CALL P_ETL_STAGE_DIM($$v_batch_date, $$v_src_sys);参数文件里写$$v_batch_date2024-06-01替换完就是CALL P_ETL_STAGE_DIM(2024-06-01, CRM)语法正确。-- 常见错法参数值里也带了引号替换后变成两对单引号 -- 参数文件里写成 $$v_batch_date2024-06-01替换结果就是 -- CALL P_ETL_STAGE_DIM(2024-06-01, CRM);两对单引号在 SQL 里表示一个转义后的单引号字符整个值就变成了字符串2024-06-01而不是日期类型不匹配报错信息通常指向参数类型转换失败跟引号问题看起来毫无关系。这个坑我见过不止一次排查方向容易跑偏到日期格式上。第二种写法参数作为对象名的一部分比如动态表名。这一层要看目标库支持不支持多数库的存储过程里不能直接把表名当参数拼得靠动态 SQL而动态 SQL 又要处理注入和权限。我的做法是不在 ETL 侧拼表名改成在存储过程里用固定的暂存表靠批次号字段区分数据来源简单得多也不容易出错。第三种写法参数值里本身含单引号比如中文名称或者备注。这种情况在参数文件里没法直接转义因为替换发生在文本层Informatica 不会帮你处理。可行的办法是把这类值改成编码或者 ID 传递让存储过程自己去查名称。把自由文本塞进 ETL 参数迟早会在某个带撇号的客户名上翻车。3.3 参数文件怎么写、放哪、怎么确认替换成功参数文件是纯文本按节组织节名跟会话名对应。[ETL_DIM_SESSION] $$v_batch_date2024-06-01 $$v_src_sysCRM $$v_stage_tableSTG_DIM_CUSTOMER节名必须跟会话名完全一致包括大小写。参数名也区分大小写$$v_batch_date和$$V_BATCH_DATE是两个不同的参数写错了不会报错只会替换成空字符串然后 SQL 变成语法错误。文件路径在工作流或者会话属性里指定建议用绝对路径相对路径的基准目录在不同版本里不一样。替换成功的确认方式我一般用一个探针语句验证而不是直接看业务表。-- 临时把 Pre SQL 换成这条跑一次就能看到参数的真实替换结果 INSERT INTO ETL_PARAM_PROBE(SESSION_NAME, P_DATE, P_SRC, RUN_TS) VALUES ($$v_session_name, $$v_batch_date, $$v_src_sys, CURRENT_TIMESTAMP);探针表是一张只有四列的日志表谁都能建跑完查一下就知道参数到底变成了什么。确认无误再把 Pre SQL 换回真正的调用语句。这个动作看起来多一步但比在存储过程里加打印、再翻会话日志快得多。参数文件改动之后工作流要重新启动才会重新读取。已经跑起来的实例不会感知文件变化这一点在调试时容易误判成“改了没生效”。4. 事务、加载模式与失败恢复调用成功不代表结果对4.1 提交间隔与存储过程内部提交的冲突Informatica 写目标的时候是按提交间隔分批提交的默认值通常是一万行。在这个窗口里目标表上持有未提交的事务。如果 Pre SQL 调用的存储过程自己也提交就会把这个窗口打乱。典型症状是会话卡在写目标表这一步数据库侧能看到长时间的锁等待会话日志里没有任何报错就是不动。原因是存储过程在 Pre SQL 阶段对目标表做了 DDL 或者显式提交后续写入时锁的持有者和等待者对不上。解决办法是把存储过程改成不提交的版本让事务边界由会话控制如果改不了就把它挪到 Post SQL 或者会话前置命令里让它的提交动作跟目标写入不在同一个时间窗口。还有一个更隐蔽的情况存储过程里对暂存表做了清空操作。清空在某些库里的行为是隐式提交这会导致会话后续的回滚失效。表现出来就是“会话失败了但目标表里已经有数据”看起来像回滚没生效实际是事务早就在清空那一步被切断了。4.2 加载方式与更新策略对执行次数的影响会话里的“源行按什么方式处理”这个选项会间接影响 Pre SQL 的执行次数。选插入、更新、删除这几种固定方式时目标只要被打开就会执行一次 Pre SQL行为比较可预期。选数据驱动方式时每行数据带一个操作标志如果所有行都被标记成删除而目标又没有配置删除操作目标可能压根不会被打开Pre SQL 也就不会执行。这时候你看到的现象是“会话成功但存储过程没跑”查日志也查不出问题因为确实没到那一步。更新策略组件同理。如果表达式把所有行都过滤掉了目标收不到数据Pre SQL 不会触发。这种“静默跳过”在数据质量波动的时候特别容易发生比如某天源表全空下游的准备工作全部没做第二天数据对不上才发现。我的做法是在存储过程内部第一行写一条审计记录记录调用时间、参数值和调用来源。跑完先查审计表再查业务表。审计表里没有记录说明调用根本没发生跟存储过程内部逻辑无关排查范围立刻缩小一半。4.3 失败重跑Pre SQL 不幂等会怎样会话失败之后重跑Pre SQL 会再执行一次。如果存储过程的逻辑是追加写入重跑就会产生重复数据如果是先删后插重跑结果是对的但中间会有一段空窗期下游如果在这个窗口里读表读到的是空。这两种情况都要求存储过程本身具备幂等性也就是同一个批次号跑一次和跑十次结果一样。实现方式通常是按批次号先删后插删除和插入放在同一个事务里中间不提交。这样重跑不会重复也不会出现空窗。还有一种失败是超时。存储过程执行时间长会话等不到返回就报错但数据库那边的过程还在跑。这时候重跑会让两个实例同时操作同一张表冲突的可能性很大。遇到这种情况先确认数据库侧那个执行会话是不是还在再决定要不要重跑不要看到报错就直接点重试。5. 避坑与排查五类最常见的翻车现场5.1 调用根本没触发Pre SQL 写了但日志里没有痕迹现象会话状态是成功存储过程没有执行暂存表还是空表。会话日志里搜不到任何跟存储过程相关的文本。原因目标在本次会话中没有收到任何行目标实例根本没有被打开Pre SQL 自然也不会下发。常见触发条件是源表当天为空、过滤器把数据全过滤掉、或者更新策略把所有行都判成了不写目标的操作。解决先确认目标是否被打开看会话日志里的写入行数统计。如果确实是零行把调用挪到会话级 Pre SQL 或者工作流的 Command Task 上这两个位置不依赖目标是否打开。如果想留在目标 Pre SQL就得在源端加一个兜底查询保证至少有一行数据流到目标比如一个恒返回一行的汇总行。5.2 参数替换成字面量报参数无效现象会话报错错误信息里能清楚看到$$v_batch_date原样出现在 SQL 文本里没有被替换成实际值。原因参数没有在会话里赋值或者参数文件的路径配错了或者参数名大小写不匹配。Informatica 的参数名区分大小写参数文件里写$$V_BATCH_DATE而语句里用$$v_batch_date替换不会发生也不会报参数未定义直接把原文下发。解决按顺序检查三件事——语句里的参数名和参数文件里的写法是否完全一致参数文件在会话属性里指定的路径是否可达工作流启动时有没有加载到这个文件。检查完用一个探针语句跑一次看落库的实际值比看日志快。5.3 绑定变量写在 Pre SQL 里语法直接报错现象报绑定变量未定义或者报语法错误错误位置指向冒号后面的变量名。原因Pre SQL 是拼接成文本发给数据库执行的没有宿主程序做变量绑定这一步。:v_batch这种写法在存储过程内部或者客户端里能用是因为那里有绑定环境在 Pre SQL 里就是一段普通文本数据库看到冒号只会当成语法错误。解决改用$$前缀的参数做文本替换。如果确实需要绑定变量的语义就在数据库侧包一层只接收固定参数的存储过程由它内部去处理Pre SQL 里只传常量或者替换后的值。5.4 报对象不存在但 DBA 说对象在现象Pre SQL 执行失败报存储过程或者表不存在DBA 查了说对象好好的权限也给过了。原因存储过程的属主是另一个用户ETL 的连接用户没有执行权限部分数据库在这种情况下报的是“对象不存在”而不是“权限不足”误导排查方向。另一个原因是存储过程内部引用对象时依赖了同义词而同义词在某些上下文里不生效。解决给 ETL 连接用户显式授予执行权限授权语句里的对象名带上属主前缀。调用语句里也带上属主前缀不依赖同义词和搜索路径。这一步做完再跑报错信息会变得有意义。5.5 存储过程内部提交与目标写入抢锁现象会话长时间卡在写目标表没有报错数据库侧能看到锁等待等待的双方一个是 ETL 连接一个是存储过程的执行会话。原因Pre SQL 调用的存储过程自己提交了事务或者执行了会隐式提交的语句把会话原本的事务窗口切断了。后续目标写入时锁的持有关系跟会话预期不一致形成互相等待。解决把存储过程改成不提交的版本事务边界交给会话控制。改不了就换挂载点挪到 Post SQL 或者工作流里的独立任务让它的提交动作跟目标写入分开。判断方法是在数据库侧查当前的锁等待关系看清楚是哪两个会话在等再决定改哪一边。6. 验证与进阶三层手段确认存储过程真的按预期跑了6.1 从日志到探针表逐层缩小范围验证这件事我的习惯是从外往里推而不是一上来就查存储过程内部逻辑。第一层看会话日志。日志里搜存储过程名能看到实际下发的语句文本和返回状态。搜不到就说明没下发问题在挂载点和触发条件上跟存储过程本身无关。这一步能砍掉一半的排查工作量。第二层看探针表。在 Pre SQL 的位置临时换成一条写日志表的语句把参数值原样落库跑一次就能看到参数的真实替换结果。参数对不对、有没有被替换成空字符串、引号有没有多出来一眼就能看出来。第三层看数据库侧的执行记录。多数数据库都保留了最近的语句执行历史能看到某条调用是什么时候进来的、执行了多久、返回什么状态。这一层能区分“根本没调用”和“调用了但失败了”对于超时类的失败特别有用。-- 探针表结构四列足够别加太多字段加多了维护成本高 CREATE TABLE ETL_PARAM_PROBE ( SESSION_NAME VARCHAR(100), P_DATE VARCHAR(20), P_SRC VARCHAR(50), RUN_TS TIMESTAMP );探针表的价值在于它是唯一一个不受存储过程内部逻辑干扰的观察点。存储过程里加打印、改逻辑、加重试都可能影响结果探针表只负责记录“我收到了什么”。6.2 把调用挪出 Pre SQL 的两种编排方式有些场景下目标 Pre SQL 这个位置本身就不合适硬留会一直出问题。两种替代编排我用得比较多。一种是工作流里的 Command Task放在会话之前或者之后用数据库客户端工具执行调用语句。好处是失败重试独立不牵连整个会话参数从工作流变量传进去跟数据流完全解耦。代价是多一个任务节点要维护编排复杂度上升。另一种是把调用包进一个独立的会话专门跑一次空数据流目标 Pre SQL 放调用语句源端用一个恒返回一行的查询。这样调用动作被隔离成独立单元失败了单独重跑不影响主数据流。代价是多占一次连接资源调度上要多一个依赖关系。两种方式都不比原方案优雅但都比“Pre SQL 挂在主数据流上、失败了整个会话重跑”可控。从那以后我每加一个 Pre SQL都强制先在存储过程第一行写一条审计记录跑完先查审计表再查业务表——这个习惯帮我省掉了很多次“到底是没调用还是调用失败”的来回确认。希望帮到你。本文还有配套的精品资源点击获取