Db2 和 Oracle 的事务回滚语义并不相同。从 Oracle 迁移过来的存储过程常会依赖语句级回滚，也就是当某条 DML 失败后，只撤销这条语句自己的修改，事务不会被强制终止。Db2 默认情况下遇到某些会让工作单元进入回滚要求状态的错误时，必须回滚整个事务才能继续操作。如果存储过程没有为这种情况准备完整的事务回滚和重试逻辑，迁移后就会出现无法捕获错误、后续语句报 SQLSTATE 40506 或类似错误。启用 opt_enable_partial_data_rollback，就是让 Db2 在数据库内部自动把失败语句的修改隔离开，让事务保持可用状态。
从 Oracle 的语句级回滚看 Db2 的差异
在 Oracle 中，事务内一条 DML 语句执行失败时，Oracle 会回滚这条语句所做的修改，但事务本身仍然有效。例如批量插入一万行数据时，某一条因为主键冲突失败，其他已经成功插入的行不会因为这一条失败而被强制撤销；程序可以捕获异常后继续处理后续数据，最后提交事务。这个行为被称为语句级回滚，也是很多数据清洗、批量加载和 ETL 流程的基础假设。
Db2 的传统事务语义更偏向整个工作单元的一致性。以唯一约束冲突 SQLSTATE 23505 为例，如果存储过程没有使用合适的错误处理或保存点，失败语句发生后，Db2 可能把当前工作单元标记为回滚必需，后续所有写操作都返回 SQLSTATE 40506，即使程序捕获了异常也无法继续执行 INSERT、UPDATE 或 DELETE。只有显式回滚整个事务，才能恢复可用状态。这种差异会导致从 Oracle 移植过来的模块，在 Db2 上出现大量运行期错误，而且排错成本通常集中在事务状态管理上。
部分数据回滚要解决的就是这个事务可用性问题。它不是把已提交的事务再拉回来，也不是无条件保留所有已成功语句；它的核心是让单条失败语句的修改被隔离并自动撤销，同时不让整个工作单元进入不可恢复状态。理解了这一点，后续启用参数才会更清楚自己的测试目标。
opt_enable_partial_data_rollback 参数的作用与启用方法
opt_enable_partial_data_rollback 是 Db2 中用于兼容 Oracle 部分回滚语义的数据库配置参数，默认值通常为 NO 或 OFF。启用后，Db2 会在支持的语句失败场景下，自动回滚失败语句产生的数据变更，而不是将整个事务标记为必须回滚。该参数对 SQL PL 存储过程、函数以及匿名块中的错误处理尤其重要。
启用前建议先备份当前数据库配置，并确认操作账户具备数据库管理员权限。启用该参数的标准做法是通过数据库配置命令完成。下面以数据库名 sample 为例：
db2 connect to sample db2 update db cfg for sample using opt_enable_partial_data_rollback YES db2 get db cfg for sample show detail
执行完更新后，可以通过 db2 get db cfg for sample show detail 查看当前值是否已经变成 YES。不同版本的 Db2 对参数生效时机的处理略有不同，有的环境断开并重新连接即可生效，有的环境需要停启实例。为避免生产环境出现配置不生效或连接异常，建议在维护窗口进行操作，并在测试库先确认行为。
如果环境中同时存在多个数据库，注意该参数是按数据库配置的，不是实例级全局参数。每个需要部分回滚语义的数据库都要单独启用。对于新建数据库，也可以在标准初始化脚本中统一配置该参数，以便自动化部署保持一致。
启用后的行为变化与保存点配合
启用 opt_enable_partial_data_rollback 后，Db2 会在内部使用隐式保存点来隔离单条语句的修改。比如在一个存储过程中连续执行三条 INSERT，第二条因为主键重复而失败，Db2 只回滚第二条插入，第一条和第三条仍然可以继续提交。这个行为和 Oracle 的语句级回滚更加接近。
下面是一个简单的 SQL PL 存储过程示例。假设测试表 t_rollback_test 已经存在，id 列是主键。存储过程先插入两条数据，然后故意插入一条重复主键，最后再插入第三条数据：
CREATE OR REPLACE PROCEDURE p_partial_test()
LANGUAGE SQL
BEGIN
DECLARE CONTINUE HANDLER FOR SQLSTATE '23505'
BEGIN
-- 忽略主键冲突，继续执行后续语句
END;
INSERT INTO t_rollback_test VALUES (1, 'first');
INSERT INTO t_rollback_test VALUES (2, 'second');
INSERT INTO t_rollback_test VALUES (1, 'duplicate');
INSERT INTO t_rollback_test VALUES (3, 'third');
END调用该存储过程并提交后，查询表内容，可以看到其中包含主键 1、2、3 的数据，但不存在值为 duplicate 的那条记录。这说明失败的那条 INSERT 被自动回滚，事务没有因为主键冲突而整体失效。如果关闭该参数，后续 INSERT 可能因为事务处于回滚必需状态而无法执行。
显式保存点仍然可以和部分回滚配合使用。比如在批量处理前设置一个保存点，当某一步失败时，程序可以先回滚到保存点，再选择跳过错误或记录到日志表。启用该参数后，即使不使用显式保存点，Db2 也会在内部为语句级回滚提供类似隔离，这降低了存储过程改造的复杂度。
验证方法与上线注意事项
验证参数是否生效，除了通过数据库配置命令查看外，还可以使用管理视图查询配置。以 Db2 提供的配置视图为例，可以执行类似下面的查询：
SELECT name, value FROM SYSIBMADM.DBCFG WHERE name = 'opt_enable_partial_data_rollback'
如果查询结果为 YES，说明配置已生效。更可靠的验证方式是直接构造一个会触发约束冲突的测试过程，观察异常处理后事务是否能继续写入。只有实际行为符合预期，才能确认该参数在当前版本和当前连接环境中真正起作用。
需要留意的是，opt_enable_partial_data_rollback 并不能覆盖所有类型的错误。像死锁、锁等待超时、连接中断等底层错误，Db2 仍会按自身的事务管理规则处理，不能假设任何异常发生后都可以继续提交。应用层仍应保留必要的显式回滚和重试逻辑。对于已经显式执行过 COMMIT 或 ROLLBACK 的代码段，参数也不会改变提交边界。
从 Oracle 迁移到 Db2 时，该参数是修复事务兼容性问题的重要手段，但它不是唯一的兼容性设置。如果应用使用了 Oracle 专用语法、保留字或内置包，还需要确认 Db2 的 Oracle 兼容模式是否已经启用。建议在功能测试和压力测试阶段，把部分回滚场景纳入用例，尤其关注批量作业、存储过程异常分支和并发写入场景。这样上线后可以避免因为事务状态不同而产生难以追踪的数据不一致问题。
