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 。