为什么PL/SQL中首次CURRENT_TIMESTAMP调用返回时间晚于第二次？

你遇到的测试失败不是逻辑错误，核心是Oracle数据库引擎的实现机制导致的：

• PL/SQL引擎和SQL引擎的时间戳获取逻辑存在差异：CURRENT_TIMESTAMP在PL/SQL上下文执行时，会直接调用内核接口获取操作系统层面的高精度实时时间；而在SQL上下文执行时，Oracle为了提升性能，会默认使用SGA中缓存的系统时间（缓存默认每10毫秒刷新一次）。如果你的存储过程执行速度足够快，SQL中UPDATE语句取到的就是还没刷新的旧缓存时间，自然会早于之前PL/SQL中取到的v_test_start_time，导致断言失败。
• 次要可能原因：如果mytable的lastchange字段定义的TIMESTAMP精度低于PL/SQL变量的精度，隐式转换时的精度截断也可能导致微小的时间偏差。

不需要加1秒这么大的误差容限，有更精准的处理方式：

• 统一时间获取上下文：把测试开始时间的获取也放到SQL上下文执行，两边用同样的缓存逻辑，就不会出现反向偏差：

PROCEDURE my_fancy_test IS
    v_test_start_time TIMESTAMP;
    v_timestamp_in_table TIMESTAMP;
BEGIN
    -- 改为从SQL上下文取开始时间，和UPDATE的时间来源一致
    SELECT CURRENT_TIMESTAMP INTO v_test_start_time FROM DUAL;

    -- 其他断言逻辑
    -- ...

    UPDATE mytable SET lastchange = CURRENT_TIMESTAMP WHERE id = 42;

    SELECT lastchange INTO v_timestamp_in_table FROM mytable WHERE id = 42;
    ut.expect( v_timestamp_in_table ).to_be_greater_or_equal( v_test_start_time );

END;

• 优先用相对变化做断言：你的测试目标是验证存储过程正确更新了lastchange字段，完全可以提前把字段设置为一个明确的旧值，之后只需要判断新值大于旧值即可，不需要和当前时间做对比：

PROCEDURE my_fancy_test IS
    v_old_timestamp TIMESTAMP := TIMESTAMP '1970-01-01 00:00:00';
    v_timestamp_in_table TIMESTAMP;
BEGIN
    -- 提前设置为明确的旧时间
    UPDATE mytable SET lastchange = v_old_timestamp WHERE id = 42;
    COMMIT;

    -- 调用待测试的存储过程
    -- ...

    SELECT lastchange INTO v_timestamp_in_table FROM mytable WHERE id = 42;
    ut.expect( v_timestamp_in_table ).to_be_greater_than( v_old_timestamp );

END;

• 如果必须对比当前时间，可以使用utPLSQL内置的近似断言，允许合理的微小误差：

-- 允许10毫秒的误差，符合Oracle时间缓存的刷新间隔
ut.expect( v_timestamp_in_table ).to_be_close_to( v_test_start_time, 0.01 );

• 涉及时间的断言优先使用相对变化判断，不要依赖跨引擎的时间绝对先后顺序，避免底层实现差异导致的非逻辑失败。
• 尽量统一时间的获取来源，避免PL/SQL和SQL上下文混合取时间的场景。
• 注意时间类型的精度和时区问题，避免TIMESTAMP WITH TIME ZONE、TIMESTAMP、DATE之间的隐式转换导致的偏差。
• RAC环境下需要注意不同节点的系统时间可能存在微小偏差，涉及跨节点操作的时间测试需要预留合理的误差范围。
• 不要假设同一会话内的时间戳永远严格递增，操作系统时钟同步、数据库时间缓存机制都可能导致极小概率的时间戳回退。

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