行版本是用于捕获表数据更改的事务一致性值吗？

Question

如果ETL进程试图检测Server中系统版本表中的数据更改，方法是将由rowversion列定义的行包含在rowversion“增量窗口”中，例如：

where row_version >= @previous_etl_cycle_rowversion
  and row_version < @current_etl_cycle_rowversion

。。@previous_etl_cycle_rowversion和@current_etl_cycle_rowversion的值是从一个日志表中选择的，该表的最新rowversion在每个ETL循环开始时被附加到所述日志表中：

insert into etl_cycle_logged_rowversion_marker (cycle_start_row_version)
select @@DBTS

..。在给定的“增量窗口”(以2 @@DBTS值为界)内的记录是否有可能由于rowversion相对于事务一致性的行为而被忽略/跳过?也就是说，rowversion是否有可能在“最终”一致性的基础上得到反映？

我想到了这样一种情况，即在单个事务中更新了1000条记录，而且@@DBTS“领先”了记录的提交rowversion，但特定版本的记录还没有可读性.

(为了确定问题的范围，请排除在如此大的批处理中删除记录或立即对给定记录进行连续更新的情况。)

Answer 1

如果确保避免对读取更改窗口的查询进行行版本控制，则不应遗漏许多行。通过读取提交的快照或快照隔离，查询中将不会出现已更新但未提交的行。

但是，您也可能错过在查询@@dbts之后更新的行。这不是什么大问题，因为他们会在下一个窗口。但是如果你有一个不断更新的行，你可能会错过很长一段时间。

但是为什么使用行版本呢？如果这些是时态表，则可以直接查询历史表。变更跟踪比使用行版本更好、更容易，因为它跟踪删除和可选列更改。该功能实际上是为了取代手动完成此功能的需要而构建的，如下所示：

通常需要做大量的工作，并且经常使用触发器、时间戳列、新表来存储跟踪信息和自定义清理过程。

。

Answer 2

在快照隔离下，检查rowversion的适当函数将确保连续的增量窗口，同时不跳过附加到长期运行的事务的rowversion值，这是MIN_ACTIVE_ROWVERSION()而不是@@DBTS。