好问题！先给你一个明确的结论：Oracle的SCN是严格单调递增的，你完全可以放心依赖SCN的数值大小来判断时间先后，不需要借助SCN_TO_TIMESTAMP函数来确保顺序。

下面具体展开解释：

• SCN的本质决定了它的严格递增性
  Oracle的系统变更号（SCN）是全局唯一、严格按顺序生成的数值。每一次数据库的变更操作（包括提交的DML、DDL，甚至数据库内部的一些维护操作）都会触发生成一个新的SCN，这个新SCN必然大于之前所有已存在的SCN。从V$DATABASE查询到的current_scn代表的是数据库当前的最高SCN，之后任何新产生的SCN都只会比它大，不可能更小。这是Oracle保证事务一致性、恢复机制正常运行的核心基础，正常运行的数据库绝不会出现SCN倒退的情况。

• SCN_TO_TIMESTAMP的作用不是判断顺序
  这个函数的核心作用是将SCN转换为对应的时间戳，方便你理解这个SCN对应的大致时间点，但它完全不是用来判断SCN顺序的工具。而且它还有局限性：Oracle只会保留最近一段时间内的SCN与时间戳的映射关系（具体时长受undo_retention等参数影响），如果你的查询间隔x分钟超过了这个保留期限，调用SCN_TO_TIMESTAMP会直接报错。所以用它来确保顺序不仅没必要，还会引入额外的风险。

• 你的业务方案完全可行
  你计划的“先记录V$DATABASE的current_scn，x分钟后查询SELECT * from mytable where ORA_ROWSCN > 之前记录的SCN”的方案，在SCN递增性的保障下是完全可靠的。只要你已经接受ORA_ROWSCN按块管理带来的多余结果（你提到此问题无关），那么这个逻辑可以准确获取到期间所有被修改过的行。

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