标签: tempdb

请帮忙，因为这个问题让我发疯......

Tempdb有四个数据文件和一个日志文件。它们都位于同一个专用驱动器上。

当我tempdb在 SQL Server Management Studio (SSMS) 中右键单击以查看属性 --> 常规...我看到“大小”为 ~65000 MB，“可用空间”为 ~64000 MB。但是，当我尝试通过 GUI 缩小文件时，我看到“当前分配的空间”没有改变并且仍然显示初始大小。

这也是“可用空间”显示为负数的地方。到目前为止，我找到的唯一解决方法是重新启动 SQL Server 以刷新tempdb，但我不能继续这样做。

有没有人遇到过这个问题，并知道它的根本原因/永久解决方案吗？

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

我得到了一个 SQL Server 2008R2 来运行，但是我的 DBA 技能在离开日常操作几年后已经生疏了，所以请忍受我（有点）愚蠢的问题。

此 SQL Server 在 Azure 中运行，具有 14GB RAM、8 个内核和 3 组条带磁盘（每组两个条带）。

每当我必须应用更新并重新启动机器时，用户都会在下一个工作日的前 20/30 分钟内体验到主要的系统减速。

在我在线检查行为的所有情况下，我能检测到的唯一显着变化是页面写入/秒的突然增加。进一步的调查表明 TEMPDB i/o ops 突然增加。然后我尝试增加 TEMPDB 的基本大小，但这仍然发生。事件查看器日志不报告任何内容。就像 SQL Server 需要在重新启动后在负载下“重新调整”自己一样。

正如我所说，减速持续 30 分钟，但这显然很烦人，我想不出阻止它的方法。

有任何想法吗？

提前致谢，

我想我需要一些帮助，因为我没有想法。

在我的数据库中，我有一个像这样的简单表：

CREATE TABLE dbo.Invoices 
( 
        CashDiscounts MONEY, 
        Cost MONEY 
) 
GO 

以及在 SELECT 上下文中使用此表的存储过程：

CREATE PROCEDURE Reporting.pLoadTest 
AS 
BEGIN 
        CREATE TABLE #t ( Test INT ); 

        SELECT  
                  Invoice.[CashDiscounts]       AS [CashDiscounts] 
                , Invoice.[Cost]                        AS [Cost] 
        FROM dbo.Invoices AS Invoice 
        LEFT OUTER JOIN #t -- if you remove this join, dm_sql_referenced_entities should return also CashDiscounts and Cost attributes
        ON 1=1 

END 
GO

现在，我遇到的问题如下：我正在使用系统函数sys.dm_sql_referenced_entities来获取Reporting.pLoadTest使用的列列表。

SELECT * 
FROM sys.dm_sql_referenced_entities ('Reporting.pLoadTest', 'OBJECT') 

我希望这个函数的结果是：

1. dbo.Invoices
2. dbo.Invoices.CashDiscounts
3. dbo.Invoices.Cost

但是，当我加入 temp #t …

正在SQL Server 2012 (11.0.6540.0)与另一台服务器一起在 AO 高可用性组中运行。

tempDB 使用量通常约为 819MB（从 2 周前开始平均超过一周），但由于我们进行了故障转移和补丁周期，tempDB 开始逐渐增长（此时未进行 DDL 更改）。我们刚刚完成了一个测试故障转移，并将 tempDB 从两台机器都可以访问的联合 SAN 驱动器上移开，（我们不希望一个硬件可以同时关闭我们的主要和次要副本）。

最近的故障转移和实例重新启动（移动 tempDB）看到 tempDB 使用量跃升至 6348MB，并且其缓慢增长。

增长全部在内部对象上，可以使用以下方法查看：

SELECT   top 5 session_id, request_id, 
         SUM(internal_objects_alloc_page_count) AS request_internal_objects_alloc_page_count
FROM     sys.dm_db_task_space_usage 
GROUP BY session_id, request_id
ORDER BY request_internal_objects_alloc_page_count DESC

看看它，它都是从 spid 35 和 32 运行的，它们都与服务代理相关。

我环顾四周，有人谈论这是由于进行WITH CLEANUP了最后的对话，但清理这个词只出现在评论中，所以我相信这不是问题。

当实例恢复并接管主节点时，服务代理不工作，所以我需要将所有队列循环到禁用然后启用状态（我们在一年前必须这样做，但没有请参阅此问题）。

您可以在此处查看 tempDB 上的使用情况，因为它目前在过去 4 天中保持不变。今天早上的下降是实例重启和故障转移。

有谁知道我缺少什么来控制它。

我们为一些 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, …

我正在一个新的 SSD 阵列上进行计时试验，该阵列同时运行 SQLIO 测试和 DB 还原和 DBCC CHECKDB 调用的实际工作负载。我发现我的 SQLIO 批处理生成的 IOPS 和吞吐量与我观察到的工作负载之间存在重大差异，工作负载仅请求我使用 SQLIO 能够观察到的一小部分，通常在 5,000 IOPS 范围内并产生不超过 400 MB/s 的吞吐量。

如果硬件有足够的容量来处理负载，那么 DBCC CHECKDB 将消耗多少资源事件是否存在固有限制？我可以尝试哪些设置来扩展 DBCC CHECKDB 对 CPU 和磁盘资源的使用？

以下是具体...

从 systeminfo

OS Name: Microsoft Windows Server 2012 R2 Standard OS Version: 6.3.9600 N/A Build 9600 System Manufacturer: HP System Model: ProLiant DL580 G7 System Type: x64-based PC Processor(s): 4 Processor(s) Installed. [01]: Intel64 Family 6 Model 46 Stepping 6 GenuineIntel ~1042 Mhz Total Physical Memory: 131,062 MB …

我在其中一台服务器（SQL Server 2008 R2）上有 tempdb 争用（我猜，至少）。

拦截器和服务员（其中 10 个）在数据库 tempdb 上都具有 PAGELATCH_EX 等待类型，并且所有会话（拦截器和服务员）的等待资源都是“2:1:122”。

我检查了 SQL 代码，发现在大多数会话中都创建了表变量，我怀疑这可能是罪魁祸首。

任何有关如何进一步诊断和缓解此问题的建议表示赞赏。