如何对比utPLSQL执行前后数据库表？求ut_package1故障根因排查方法

一、怎么对比ut_package2执行前后的数据库表数据变化 #

当然可以，你可以用这几种方法实现：

• 建数据快照表：跑ut_package2之前，把ut_package1依赖的所有表数据复制到临时快照表，跑完之后用MINUS语句对比差异。
  示例代码：

  -- 先给目标表建快照（以example_table为例）
  CREATE TABLE example_table_snap AS SELECT * FROM example_table;
  
  -- 执行ut_package2
  BEGIN
    ut_package2.run();
  END;
  /
  
  -- 找执行后新增/修改的数据
  SELECT * FROM example_table
  MINUS
  SELECT * FROM example_table_snap;
  
  -- 找执行后删除的数据
  SELECT * FROM example_table_snap
  MINUS
  SELECT * FROM example_table;
  

• 用闪回查询：如果数据库开了闪回功能，直接查执行前后的时间点数据就行，不用建快照。
  示例代码：

  -- 先记下来ut_package2执行前的时间戳
  DECLARE
    v_before_time TIMESTAMP;
  BEGIN
    SELECT SYSTIMESTAMP INTO v_before_time FROM dual;
    
    -- 执行ut_package2
    ut_package2.run();
    
    -- 对比前后数据差异
    DBMS_OUTPUT.PUT_LINE('新增/修改的数据：');
    FOR rec IN (SELECT * FROM example_table MINUS SELECT * FROM example_table AS OF TIMESTAMP v_before_time) LOOP
      -- 输出或处理差异数据
    END LOOP;
    
    DBMS_OUTPUT.PUT_LINE('删除的数据：');
    FOR rec IN (SELECT * FROM example_table AS OF TIMESTAMP v_before_time MINUS SELECT * FROM example_table) LOOP
      -- 输出或处理差异数据
    END LOOP;
  END;
  /
  

• 开utPLSQL的测试隔离：utPLSQL本身支持测试隔离，比如把每个测试包放独立会话或事务里跑，避免互相影响。如果必须一起跑，让ut_package2执行完后显式回滚或者重置会话状态。

二、排查ut_package2搞挂ut_package1的隐藏原因 #

你说两个包没共用数据，ut_package2也做了清理，但还是出问题，大概率是隐藏的会话级或系统级影响，重点查这些：

• 序列被改了：ut_package2可能用了ut_package1依赖的序列，哪怕业务数据清了，序列的当前值被改了，ut_package1插数据时就会触发主键重复之类的约束错误。
  验证：跑ut_package2前后查序列值：SELECT sequence_name, last_number FROM user_sequences WHERE sequence_name = '你的序列名';
• 全局临时表残留数据：如果ut_package2用了全局临时表，没在测试结束清干净，同一会话里ut_package1跑的时候就会读到残留数据，逻辑出错。
• 会话参数被改：ut_package2可能改了会话级参数（比如NLS_DATE_FORMAT、OPTIMIZER_MODE），或者设了会话变量，导致ut_package1的执行环境变了，跑不起来。
  验证：跑前后查会话参数：SELECT name, value FROM v$parameter WHERE is_session_modifiable = 'TRUE';
• 触发器隐式影响：ut_package2的操作触发了全局触发器（比如行级触发器、系统触发器），间接改了ut_package1依赖的元数据或数据。
• 权限残留：ut_package2测试时临时调了权限，哪怕之后恢复了，会话级的权限可能没重置，影响ut_package1。

三、根因分析（RCA）的实用方法 #

1. 逐步隔离测试：
   • 单独跑ut_package1，确认没问题；
   • 单独跑ut_package2，确认没问题；
   • 先跑ut_package2，立刻跑ut_package1，复现故障；
   • 换不同会话分别跑两个包，看还会不会出问题（判断是不是会话级影响）。
2. 拆包排查：
   • 把ut_package2的测试用例拆成单个，跑一个就测一次ut_package1，定位到具体哪个用例搞的鬼。
3. 加日志和追踪：
   • 给ut_package2加详细日志，记录所有DDL/DML、参数修改、序列调用；
   • 用DBMS_MONITOR开SQL追踪，记录ut_package2执行期间的所有数据库操作。
4. 验证环境一致性：
   • 确认现在的测试环境版本、参数和之前ut_package1正常跑的时候一样；
   • 检查有没有其他并行任务或脚本在干扰测试环境。

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