Pentaho ETL插入超1100条记录卡住、步骤等待设置问题

数据写入停滞锁表问题（Table Output步骤插入1100条后无响应） #

• 调整批量提交配置：打开Table Output步骤配置页，将*Commit size（提交记录数）*调整为1000-5000区间，禁止设置为0（0代表全量攒批提交，长事务极易触发数据库锁等待超时），同时勾选「Use batch insert（批量插入）」选项，降低单条提交带来的事务持有时间和网络开销。
• 排查数据库端僵尸锁：出现固定条数卡顿时，直接查询对应数据仓库的锁视图（MySQL查information_schema.innodb_locks、PostgreSQL查pg_locks、Oracle查v$locked_object），定位是否有历史失败残留的Pentaho进程、后台运维任务持有目标表的锁，手动kill掉僵尸会话后重试即可。
• 校验临时表作用域：确认read from temp table读取的临时表为当前转换会话独享的会话级临时表，如果是全局临时表，跨会话的写入/修改操作会导致插入步骤出现隐式等待，更换为会话级临时表即可避免跨会话干扰。
• 匹配JDBC驱动版本：社区版Pentaho自带的JDBC驱动普遍存在版本滞后问题，和高版本/特定版本数据仓库对接时，批量写入达到特定阈值就会出现协议阻塞，替换为和数据仓库大版本完全匹配的JDBC驱动jar包到Pentaho安装目录的lib文件夹下，重启服务后即可修复。

步骤时序强制控制配置方法 #

• 转换内部步骤依赖：如果需要同一个转换内的后续步骤等前置步骤完全执行完再启动，不能直接用跳连线连接两个步骤，需要在两个步骤中间添加Block this step until steps finish步骤，在配置页选中需要等待的所有前置步骤，即可保证前置步骤处理完全部数据、释放资源后再触发后续步骤。
• 作业级作业项依赖：作业内的作业项默认是串行执行的，出现偶发提前触发的核心原因是前置作业项的成功判定规则不严谨：
  • 打开前置DDL类作业项（比如对象创建脚本）的配置页，勾选「仅当脚本无执行错误时标记为成功」，取消勾选「单条语句模式发送SQL」，如果脚本包含多条DDL，要确保驱动能拿到每条语句的明确执行成功响应，避免驱动提前返回成功但DDL实际还在后台执行。
  • 对于强一致性依赖的流程，可以在两个作业项中间添加Wait for作业项，配置检测规则（比如检测目标表是否存在、目标表是否无锁），设置2-5秒的检测间隔和合理的超时时间，即可彻底解决时序错位导致的执行失败。
• 注意事项：不要在同一个转换内同时放置DDL执行步骤和数据写入步骤，转换内部默认是并行流执行逻辑，DDL持有的元数据锁极易和写入步骤的事务锁冲突，所有DDL类操作统一放到作业层级做串行调度。

内容的提问来源于stack exchange，提问作者Andrey