标签: tempdb-version-store

根据 Kimberly L. Tripp 的 MSDN 文章，Neal Graves 的“ SQL Server 2005 Row Versioning-Based Transaction Isolation

• “...特定记录的所有早期版本都链接在一个链表中；并且在基于行版本控制的长时间运行的事务的情况下，必须在每次访问时遍历该链接以到达事务一致的版本行”

这在“了解行版本控制”部分中是常见的“使用行版本控制读取提交中的行版本控制”和“快照隔离中的行版本控制”部分。

进一步关于由于修改导致的行版本控制的示例仅在 SNAPSHOT 中的多个事务（T1、T2、T3）对同一记录的多次更新的上下文中给出。

如果只有一个事务多次更新记录（通过多个语句），是存储（链接）多个版本存储还是仅在拍摄快照“图像”时拍摄的一个？

好吧，这个问题的答案应该立即回答我其他未决的相关问题：

• 为什么行版本隔离使用记录版本的链接列表？
• RCSI 使用的空间是否比 SNAPSHOT 少或相同？为什么？

今天我们遇到了一个错误：

错误：3967，严重性：17

据我所知，它基本上是“完整版商店”。这提出了一些我难以回答的问题，因为在我的商店，我们以前从未遇到过这个错误：

• 如果有预设的最大大小（基于总tempdb大小或其他），它是动态的吗？

• 如果不是，是否有设置可以使其动态化？

• 我们可以基于此设置警报吗？（即用于跟踪大小等的 DMV）

SQL Server 有一个选项SET STATISTICS IO ON可以显示查询的逻辑和物理页读取次数。这些统计信息是否包括 SNAPSHOT 和 RCSI 查询的版本存储读取？

据我所知，版本存储只会清理比最旧的活动事务旧的版本。问题：最旧的事务数据库是特定的还是 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

参考文档：
TempDB 2005 WP
Teratrax tuning tempDB …

试图更好地理解基于行版本控制的事务隔离 - RCSI（读取提交的快照隔离和快照） - 在 SQL Server 中...

MSDN 在线文章“选择基于行版本控制的隔离级别”指出：

• *“对于大多数应用程序，由于以下原因，建议使用行版本控制读取提交隔离而不是快照隔离：
  • 它比快照隔离消耗更少的 tempdb 空间"*

这与 Kimberly L. Tripp、Neal Graves 的“ SQL Server 2005 Row Versioning-Based Transaction Isolation ”中的陈述相矛盾：

• “使用行版本控制的读提交中的行版本控制
  对于在使用行版本控制的读提交下运行的查询，行版本仅在事务中每个 SELECT 语句的持续时间内是必需的。但是，行版本会一直保持到事务结束。这是 tempdb 存储需要考虑的重要一点。存储影响将与快照隔离相同。 ”

那么，为什么 RCSI 使用更少（或相同）的空间？

更新：
可能我把最初的问题表述得很糟糕，但这意味着对这两个相互矛盾的“理论”都有 RTFM 解释和确认，我想明白：
哪个是正确的？
为什么一个真的是正确的？
而
为什么不是另一个真正正确的（为什么是另一种错？）？

子问题：

如果在单个事务中对同一记录进行多次更新，将存储多少个版本？

我们为一些 SQL Server 2005 数据库启用了“READ_COMMITTED_SNAPSHOT”。

现在我们不时看到我们的 TempDB 正在填满硬盘，我们怀疑版本存储是罪魁祸首。

我们监视 TempDB 的使用情况sys.dm_db_file_space_usage，一旦我们看到版本存储在增加（如 所报告的那样 version_store_reserved_page_count），我们希望识别正在使用版本存储的事务。

我正在使用以下语句来查找使用版本存储的事务：

SELECT db_name(spu.database_id) as database_name,
       at.transaction_begin_time as begin_time,
       case 
         when at.transaction_state in (0,1) then 'init'
         when at.transaction_state = 2 then 'active'
         when at.transaction_state = 3 then 'ended'
         when at.transaction_state = 4 then 'committing'
         when at.transaction_state = 6 then 'comitted'
         when at.transaction_state = 7 then 'rolling back'
         when at.transaction_state = 6 then 'rolled back'
         else 'other'
       end as transaction_state,
       ast.elapsed_time_seconds as elapsed_seconds,
       ses.program_name, …

我试图了解 SQL Server 版本存储和相关的隔离级别。据我了解，当数据库启用读取已提交快照选项时，可能会发生这种情况：

• 数据库中的商品 (id = 1) 价格为 1000 美元
• 会话 1 开始一条更新语句：update products set price = price * 1.5。由于这涉及表的所有行，因此需要很长时间。
• 当update语句仍在进行时，会话 2 启动一个查询：select * from products where id = 1。由于数据库处于读已提交快照模式，因此写入者不会阻止读取者。因此，会话 1 从版本存储中读取该行的旧版本，并认为该产品的价格为 1000 美元。
• 会话1的用户觉得价格还不错，所以决定购买。但 ...
• 在用户将产品添加到购物车之前，上述update语句执行完毕，产品（id = 1）的新价格为 1500 美元。如果用户知道产品的新价格，他就不会购买。

在这种情况下，会发生什么呢？这种情况实际上可能吗？如果是这样，防止这种情况的规范是什么？