rowversion 是用于捕获表数据更改的事务一致值吗

Question

如果 ETL 进程尝试通过将rowversion列定义的行包含在rowversion “增量窗口”中来检测 SQL 服务器中系统版本表上的数据更改，例如：

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

...是否有可能由于rowversion的行为相对于事务一致性而错过/跳过落入给定“增量窗口”（由 2 个@@DBTS值限制）内的记录的rowversion ？ - 即，是否可能基于“最终” rowversion来反映行版本？

我正在考虑这样一种情况，即在单个事务中更新了 1000 条记录，并且不知何故@@DBTS比记录的已提交rowversion “领先”，但该记录的特定版本尚不可读......

（为了确定问题的范围，请排除在如此大的批量事务中删除记录或立即连续更新给定记录的任何情况。）

Answer 1

如果您确保避免对读取更改 windows 的查询进行行版本控制，您不应该错过很多行。 使用 READ COMMITTED SNAPSHOT 或 SNAPSHOT ISOLATION 更新但未提交的行不会出现在您的查询中。

但是您也可能会错过查询@@dbts 后更新的行。 这通常没什么大不了的，因为它们将出现在下一个 window 中。 但是，如果您有一个不断更新的行，您可能会错过很长时间。

但为什么要使用 rowversion？ 如果这些是临时表，您可以直接查询历史表。 并且更改跟踪比使用 rowversion 更好、更容易，因为它可以跟踪删除和可选的列更改。 该功能实际上是为了取代手动执行此操作的需要：

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

.

Answer 2

在 SNAPSHOT 隔离下，结果是正确的 function 来检查rowversion ，这将确保连续的增量 windows 而不会跳过附加到长时间运行事务的rowversion值是MIN_ACTIVE_ROWVERSION()而不是@@DBTS 。