Oracle ORA#U ROWSCN-旧的/修复的块不'；没有分配真正的SCN？

我们使用ORA_ROWSCN伪列来定位最近修改的行，以便将选定的详细信息复制到不同的数据源。我们知道该列的“近似”性质，如果块中只有一行发生了更改，那么块中的整批行都会用SCN标记，我们对此没有意见，相对较小的误报批次不是问题

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

会话#SCN下的1-400万行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

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

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下的200-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   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   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   27501528

会话#SCN下的300-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   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   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   27501528

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

是否有人可以确认A。这实际上就是我们看到的，B。也许这是Oracle Pump实用程序和C的已知效果。如果我们只是用新的更新标记这些行，它们将永久移出“浮动”SCN，从而解决我们的问题

注:

我们知道SCN不准确，是每个区块的

我们对“为什么不使用替代技术X？”不感兴趣。答案是，我们知道其他技术，如果我们决定，我们将使用它们，我们只是试图理解这个确切的行为

A） 你所看到的是其他人遇到的一个真正的问题。B） 这个问题不仅仅是由数据泵引起的。C） 更新将有助于解决问题，但您不能指望它始终有效

ORA_ROWSCN既不准确也不一致。报告只提到了不准确之处。这清楚地表明，对于您试图做的事情，

ORA_ROWSCN

是多么不合适：

如果一个块被查询两次，那么 ORA_ROWSCN在查询之间进行更改，即使行尚未更改 已在两次查询之间的时间内更新

我不确定是什么原因导致会话之间发生变化，但我不认为这仅仅与数据泵有关。大约5年前，当我第一次遇到这个问题时，我们从未找到一个模式，如果我没记错的话，我们甚至没有使用数据泵

我们的问题尤其是Oracle SQL Developer，它使用

ORA_ROWSCN

进行乐观锁定。真是令人讨厌。用户将进行更改，当他们去提交时，他们被错误地告知其他人已经更改了行。正如您现在所做的，我们发现如果对行应用任何类型的更改，问题就会消失。我记不起它有多有效，但你不应该假设它在100%的时间内都有效

---

据我所知，没有人能确切解释ORA_SCN是如何设置的以及它将返回什么。当您需要准确或可重复的结果时，不应使用此选项。

非常有趣！“从时间戳到时间戳（“插入间隔时间”）的t1中选择*得到了什么？实际上，我们使用SCN只是为了比查询整个表中的更改做得更好，所以准确性并不像拥有一个不移动的SCN那么重要。但我们只是希望在我们运行的每个作业中不会有数百万行移动。好吧，11g章节中的额外文档可能已经吓到我们，让我们像其他人一样使用触发器。