因此，这基本上是关于Finding duplicate records的后续问题。
我们每天从文本文件执行数据导入，最后导入了两次分布在182个文件中的10163条记录。在运行上述查询以查找重复项时，我们获得的记录总数为10174，比文件中包含的记录多11个记录。我假设2个记录的可能性完全相同，并且在查询中也考虑了有效记录。所以我认为最好使用时间戳字段并简单地找到今天运行的所有记录（因此最终添加重复的行）。我使用ORA_ROWSCN使用以下查询：
select count(*) from my_table
where TRUNC(SCN_TO_TIMESTAMP(ORA_ROWSCN)) = '01-MAR-2012'
;
但是，计数仍然更多，即10168.现在，我非常确定通过在包含所有文件的文件夹中运行以下命令，文件中的总行数为10163。 wc -l *.txt。
是否可以找出实际插入两次的行？
答案 0 :(得分：14)
默认情况下，ORA_ROWSCN存储在块级别，而不是行级别。如果表最初是在启用ROWDEPENDENCIES的情况下构建的，则它仅存储在行级别。假设您可以在一个块中放置表的多行，并且您没有使用APPEND提示将新数据插入到表的现有高位标记之上，则可能会将新数据插入到已经有一些现有数据的块。默认情况下，这将更改块中每行的ORA_ROWSCN，从而导致查询计算的行数比实际插入的数量多。
由于ORA_ROWSCN仅保证在最后一行中有DML的上限，因此通过添加{{1}来确定今天插入了多少行将更为常见在CREATE_DATE运行后默认为SYSDATE或依赖SQL%ROWCOUNT的表的列（当然，假设您使用单个INSERT语句插入所有的行。）
通常，即使使用INSERT构建表，使用ORA_ROWSCN和SCN_TO_TIMESTAMP函数也会成为识别何时插入行的有问题的方法。 ROWDEPENDENCIES返回一个Oracle SCN，它是一个系统变更号。这是特定变更（即交易）的唯一标识符。因此，SCN与时间之间没有直接联系 - 我的数据库可能比您的数据库生成SCN快一百万倍，而且我的SCN 1可能与您的SCN相差多年.1。Oracle后台进程{{1}维护一个表格，将SCN值映射到近似时间戳，但它只在有限的时间内维护该数据 - 否则，您的数据库最终会得到一个数十亿行表，它只是将SCN存储到时间戳映射中。如果插入的行超过一周前（并且确切的限制取决于数据库和数据库版本），ORA_ROWSCN将无法将SCN转换为时间戳并返回错误。