SCN 本身是编码时间戳还是从某个表中查找。
从 AskTom 帖子中,他解释说 +/-3 秒的时间戳存储在 smon_scn_time 的原始字段中。这是函数将获得价值的地方吗?
如果是这样,那么该表何时被清除(如果有的话)?如果是这样,是什么触发了清除?
如果是,那是否就无法将旧的 SCN 转换为时间戳?
如果这是不可能的,那么它将消除该领域的任何长期使用(阅读:审计)。
如果我将该函数放入查询中,加入该表会更快吗?
如果是这样,有人知道如何隐藏那个 Raw 列吗?
SCN 本身是编码时间戳还是从某个表中查找。
从 AskTom 帖子中,他解释说 +/-3 秒的时间戳存储在 smon_scn_time 的原始字段中。这是函数将获得价值的地方吗?
如果是这样,那么该表何时被清除(如果有的话)?如果是这样,是什么触发了清除?
如果是,那是否就无法将旧的 SCN 转换为时间戳?
如果这是不可能的,那么它将消除该领域的任何长期使用(阅读:审计)。
如果我将该函数放入查询中,加入该表会更快吗?
如果是这样,有人知道如何隐藏那个 Raw 列吗?
SCN 不编码时间值。我相信这是一个自动递增的数字。
我猜想 SMON 每次增加 SCN(包括当前时间戳)时都会在 SMON_SCN_TIME(或它下面的任何表)中插入一行。
我查询了几个数据库中记录的最小时间戳,它们都可以追溯到大约 5 天,并且表中的行数略低于 1500 行。所以它小于实例生命周期。
我想数据保留时间的下限可能由 DB_FLASHBACK_RETENTION_TARGET 参数确定,默认为 1 天。
我建议使用该功能,他们可能已经提供了它,因此他们可以随意更改内部结构。
不知道 RAW 列 TIM_SCN_MAP 包含什么,但 TIME_DP 和 SCN 列似乎会为您提供映射。