然而,我们观察到的是大量行,似乎具有“浮动”ORA_ROWSCN值.这些是数百万行,当然没有改变,但是每次我们开始与Oracle进行新的控制台会话时,每一行都会有一个全新的,最新的SCN.下面说明了几分钟内的三个独立的控制台会话：

会议#1 – 400万行SCN 27501512：

sql> SELECT count(*),ORA_ROWSCN FROM our_table GROUP BY ORA_ROWSCN ORDER BY ORA_ROWSCN;

  COUNT(*) ORA_ROWSCN
---------- ----------
    12   27323587
    12   27415360
    20   27431509
   4057846   27501512

会议#2 – SCN下的400万行27501522：

sql> SELECT count(*),ORA_ROWSCN FROM our_table GROUP BY ORA_ROWSCN ORDER BY ORA_ROWSCN;

  COUNT(*) ORA_ROWSCN
---------- ----------
    12   27323587
    12   27415360
    20   27431509
   4057846   27501522

会议#3 – SCN下的400万行27501528：

sql> SELECT count(*),ORA_ROWSCN FROM our_table GROUP BY ORA_ROWSCN ORDER BY ORA_ROWSCN;

  COUNT(*) ORA_ROWSCN
---------- ----------
    12   27323587
    12   27415360
    20   27431509
   4057846   27501528

这是一个测试数据库,没有其他进程正在修改行.我们的理论是,由于某些原因,这个四百万块的行没有专用的“SCN”,因为这些行使用Oracle数据泵工具转移到这个数据库中,也许包含它们的块没有正确的分配SCN.因为没有其他值可用,Oracle然后别无选择,只能为这些行提供最高可能的SCN,对应于当前的SCN值.当我们更新这些行时,甚至没有意义的是,他们移出400万个“浮动”SCN的块,并获得一个固定的SCN号码.其余的行继续移动.

有人可以确认A.这实际上是我们看到的,或许如果这是Oracle Pump实用程序和C的已知效果,那么如果我们使用新的UPDATE标记这些行,它们将永久移动走出“浮动”的SCN,从而解决了我们的问题？

笔记：

>我们知道SCN是不准确的,是每个块.
>我们对“为什么不用替代技术X？”感兴趣？答案,我们知道其他技术,如果我们决定,我们将使用它们,我们只是想了解这个确切的行为.