根据 Kimberly L. Tripp 的 MSDN 文章，Neal Graves 的“ SQL Server 2005 Row Versioning-Based Transaction Isolation
这在“了解行版本控制”部分中是常见的“使用行版本控制读取提交中的行版本控制”和“快照隔离中的行版本控制”部分。
进一步关于由于修改导致的行版本控制的示例仅在 SNAPSHOT 中的多个事务（T1、T2、T3）对同一记录的多次更新的上下文中给出。
如果只有一个事务多次更新记录（通过多个语句），是存储（链接）多个版本存储还是仅在拍摄快照“图像”时拍摄的一个？
好吧，这个问题的答案应该立即回答我其他未决的相关问题：
sql-server transaction tempdb-version-store snapshot-isolation
据我所知，版本存储只会清理比最旧的活动事务旧的版本。问题：最旧的事务数据库是特定的还是 SQL Server 将保留所有版本，无论数据库如何，如果有一个较旧的事务仍然处于活动状态，期间？
Backstory - SQL Server 2005 SP4 Enterprise 托管大约 40 个数据库。TempDB 当前为 102 GB，版本存储约为 98 GB。数据库实例上托管的应用程序之一有一个基于 sys.dm...database_transactions 的 40 天前的打开事务。两个独立的大型数据库在上个月的使用量非常大，我们看到与这些操作一致的 TempDB 增长。我们预计会有一些增长。我们没想到它会继续增长。 问题：存储在 TempDB 版本存储中的来自这两个独立数据库的版本是否仍然存在，因为第三个独立数据库具有 40 天前的连接并显示打开的事务状态？
Perfmon 计数器：在我今天早上跟踪它的几个小时内，版本存储不断增长。版本生成速率 AVG 约为 30 kb/s，版本清理速率为 0 kb/s。
为 TempDB 留下了大量空间，所有用户数据库的数据文件总数约为 300 GB，自上次重新启动以来，TempDB 的 8 个数据文件中的每一个每天平均增长 350 MB。此行为异常，调查发现大版本存储
对评论问题的回答，以免出现长时间运行的评论部分：
问：为什么在 tempdb 上自动增长？答：TempDB 设置为以我们认为适合大多数时间的大小进行初始化。我们允许自动增长以处理异常的数据库活动。我们也监控自动增长。
问：你怎么知道事务是活跃的，而不仅仅是一个活跃的连接？A：transaction_state 表示在 sys.dm_tran_active_snapshot_database_transactions 和其他东西中处于活动状态。活动监视器说每个连接有 1 个打开的事务。
问：为什么你的应用程序如此愚蠢？A：第三方。此实例中的众多实例之一。我不知道这种行为是否异常，或者很容易修复。
解析度
开放交易（或多个），其中防止任何版本存储清理，乔恩是正确的，版本存储清理是数据库地独立。关闭违规事务允许开始版本存储清理。原因背后的当前理论来自 Jon Seigel
版本存储只能根据整个实例内最旧的活动事务清除版本，以支持同时跨多个数据库使用事务级快照隔离。
如果有人确切知道或可以证明这一点，请这样做
参考问题：find-transactions-that-are-filling-up-the-version-store