为了将选定的细节复制到不同的数据源,我们正在使用ORA_ROWSCN伪列来定位最近修改的行.我们知道这个列的“近似”性质,如果块中只有一行已经改变,则块中的整行批量标记为SCN,并且我们可以理解,相对较小批次的误报不是问题.
然而,我们观察到的是大量行,似乎具有“浮动”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?”感兴趣?答案,我们知道其他技术,如果我们决定,我们将使用它们,我们只是想了解这个确切的行为.