12

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

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

会话 #1 - SCN 27501512下的 400 万行：

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 27501522下的 400 万行：

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 27501528下的 400 万行：

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. 这实际上是我们所看到的 B. 也许如果这是 Oracle Pump 实用程序的已知效果和 C. 如果我们只是用新的 UPDATE 标记这些行，它们将永久移动脱离“浮动”SCN 从而解决我们的问题？

笔记：

  1. 我们知道 SCN 不准确，而且是按块计算的。

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

4

1 回答 1

3

A) 你看到的是其他人遇到的真正问题。B) 这个问题不仅是由 Data Pump 引起的。C）更新将有助于解决问题，但您不能依赖它始终工作。

ORA_ROWSCN 既不准确又不一致。10g 文档只提到了不准确之处。11g 文档清楚地说明ORA_ROWSCN了您尝试做的事情有多不适合：

如果一个块被查询两次，那么 ORA_ROWSCN 的值可能会在两次查询之间发生变化，即使在两次查询之间没有更新行。

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

我们的问题特别是ORA_ROWSCN针对用于乐观锁定的 Oracle SQL Developer。 这个错误非常烦人。用户会进行更改，当他们提交时，他们被错误地告知其他人已经更改了行。就像您现在所做的那样，我们发现如果我们对行应用任何类型的更改，问题就会消失。我不记得它的效果如何，但你不应该假设它会在 100% 的时间内有效。

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

于 2014-05-09T06:09:10.787 回答