标签: tempdb

负责监视和调整 SQL Servers 2012 Enterprise Ed。Windows Server 2008 R2 Standard Ed 上的 SP1（64 位）。

所有这些都在虚拟机中运行。单个 RAID10 或 RAID5 上的每个区域办事处一个 SQL Server。换句话说，我无法使用不同的物理单元（硬盘驱动器）配置 SQL Server。

我观察到tempdb系统数据库上的读取和写入延迟升高。
在减少tempdb数据库延迟方面，我有哪些选择？

根据我的阅读，配置 tempdb 的最佳实践包括创建多个数据文件。我理解的经验法则是，如果您应该创建与最多 8 个逻辑处理器相同数量的数据文件。然后，如果您有 tempdb 争用，请添加一个额外的文件，直到争用消失或您有每 4 个额外的逻辑处理器添加一个额外的文件。因此，如果您有 16 个逻辑处理器，那么您最多可以创建 10 个文件。

我很好奇的是 MAXDOP 是否会对此产生影响？因此，例如，如果我有 12 个逻辑处理器。我已将 MAXDOP 设置为 6，因为它们被分成 2 个 NUMA 节点。这是否意味着我应该为 tempdb 坚持使用 6 个数据文件？或者我是否仍然拥有推荐的处理器总数的 8 或 9？

我最近将临时数据库文件移到了一个单独的驱动器上（我有两个数据文件和一个日志文件）。

但是，重新启动服务器后，我的第二个数据文件从 gui 上的文件列表和 sp_helpfile 中都消失了。我设法多次重现此行为：我添加了一个新数据文件，看到它同时出现在 gui 和 sp_helpfile 中，并在重新启动服务器后消失。

我dbcc checkdb对数据库运行过，它没有返回任何错误。SQL 日志或 Windows 应用程序事件日志中都没有信息。

在做了更多研究之后，我运行了以下查询：

select d.name, m.* from sys.master_files m
inner join sys.databases d 
on (m.database_id = d.database_id)
where d.name like 'tempdb'
order by 1, 2

结果：http : //pastebin.com/Zu5fJ2hU

它显示了四个不同的辅助数据文件，其中没有一个出现在 sp_helpfile 中。如果我尝试使用 SQL Server 不允许使用的任何名称。这些文件都不存在于磁盘上。我的服务器是 SQL 2012 标准版。

IFI（即时文件初始化）是否与tempdb增长兼容？最近我需要将我的tempdb增加40 Gb，花了 15 多分钟才完成。我验证了该用户已被添加到执行值维护任务，并验证了其他用户数据库需要几秒钟才能完成。

我没有找到任何文档或链接，其中包含有关TempDB的深入 IFI 详细信息。我非常感谢您的建议。

我有一个进程渴望 tempdb，但我正在努力识别这个进程。

我有什么方法可以实现这一目标？

\n

我们已收到警报，因为 Tempdb 现在已占据您之前在 T:\\ 驱动器上回收的空间。同样，磁盘上还剩余 10MB。从今天早上 10:18 开始，我可以在 REP 实例上的数据文件中看到许多自动增长事件。总共有 330 个自动增长事件，每个事件大小为 512MB，总计 168GB。

\n\n

事后很难强调什么在 Tempdb 中使用了这个空间，您是否知道今天有任何进程可能以这种方式使用 Tempdb？

\n

/ ------------------------------------------------- ----------- \\

确定自动增长事件发生的频率

当 SQL Server 执行自动增长事件时，触发自动增长事件的事务必须等到自动增长事件完成后才能完成。当自动增长事件发生时，这些自动增长事件会导致您的性能略有下降。因此，最好能够适当调整数据库大小，以便很少发生自动增长事件。

如果您对系统上自动增长事件发生的频率感兴趣，您可以使用跟踪捕获这些事件。通过了解哪些数据库正在执行自动增长事件，您可以调整这些数据库文件增长属性，以便它们执行自动增长事件的频率降低。您可以使用探查器 \xe2\x80\x9cData File Auto-grow\xe2\x80\x9d 和/或 \xe2\x80\x9cLog File Auto-grow\xe2\x80\x9d 事件来跟踪这些数据库自动增长事件。如果您运行的是 SQL Server 2005 或更高版本，则默认跟踪已捕获这两个自动增长事件。如果您还没有\xe2\x80\x99t 关闭默认跟踪，那么您可以使用默认跟踪文件来查找这些自动增长事件。如果您已关闭默认跟踪，则可以启用它，或者设置新的探查器跟踪以捕获 \xe2\x80\x9cData File Auto-grow\xe2\x80\x9d 和 \xe2\x80\x9cLog File Auto-grow \xe2\x80\x9d 事件。

默认跟踪记录到文件中。我在清单 4 中提供了代码，向您展示如何从默认跟踪文件中提取所有自动增长事件。如果您创建自己的探查器跟踪会话来捕获这些自动增长事件，那么您将需要修改此脚本以满足您的探查器跟踪设置。

https://www.simple-talk.com/sql/database-administration/sql-server-database-growth-and-autogrowth-settings/

马塞洛·米奥雷利\n2014 年 3 月 11 日

\\*--------------------------------------------------*/\nDECLARE @filename NVARCHAR(1000);\nDECLARE @bc …

几天前，我们已经从 2012 年服务器迁移到 2014 年，我们保留了与之前相同的设置，例如我们在 Tempdb 中使用 8 个数据文件以获得更好的性能，并且全部放置在单个驱动器中。

由于这是数据仓库环境，批量加载连续运行，并且 tempdb 驱动器已满。即使数据库中有 98% 的可用空间，它也无法重用空间并导致磁盘已满。

tempdb 中没有足够的空间来保存行版本。需要缩小版本存储以释放 tempdb 中的一些空间。事务（id=239368387 xsn=1273322 spid=126 elapsed_time=1590）已被标记为受害者，如果它访问版本存储，它将被回滚。如果问题仍然存在，可能的原因是临时数据库大小不正确或事务长时间运行。请参阅 BOL 了解如何配置 tempdb 进行版本控制。

问题

1. SQL Sever 2014 中是否有任何特定的 tempdb 设置可以避免这些问题？

2. 对于 tempdb 性能改进有什么建议，例如启用跟踪标志 -T1118 吗？

2012 年，它只需要 64 GB，现在甚至 450 GB 也不够用。

服务器规范。

SQL Server 检测到 4 个插槽，每个插槽 15 个核心，每个插槽 30 个逻辑处理器，总共 120 个逻辑处理器；使用基于 SQL Server 许可的 120 个逻辑处理器。512 GB 内存。

我有一个 HR 软件，HR 部门的一名员工在该软件上每年运行大约两次长时间且复杂的分析和计算。因此，它tempdb正在增长到 500GB 甚至更多。

什么是好的磁盘大小调整解决方案？因为今年剩下的时间tempdb没有那么大。

细节

• SQL Server 版本和相关版本是 2017 标准版。
• tempdb和数据库在同一个分区上D:，日志文件在不同的分区上E:
• HR 数据库本身大约有 78GB。

几个月以来，我一直在努力解决这个问题，我说这不是数据库问题，并将此案例分配给存储和操作系统团队，然后他们将其分配给我。这个问题反复发生，没有任何定义的发生模式。

我检查了这里提出的相同问题，我可以说这不是数据库损坏的问题，因为我使用 Ola Hallengren 的脚本进行维护工作，并且每周对用户和系统数据库进行数据库完整性检查（checkdb），并且没有报告任何问题在那里面。

也针对类似问题访问了第二个链接，可以确认 tempdb 处于简单恢复状态。

我为数据和日志添加了一个额外的文件，这样如果一个文件不可用，另一个文件仍然可以访问，但是后来我知道 tempdb 的访问是顺序的，因此只有当第一个文件已满时它才会转到第二个文件：

每次出现此问题时，我都可以看到 Windows 应用程序日志中还有另一个错误，如下所示：

SQLServerLogMgr::LogWriter: Operating system error 170(The requested resource is in use.) encountered.

存储团队已将这些文件从防病毒扫描中排除。

这里需要注意的一件事 - 我检查了其他系统数据库及其文件位置，可以看到对于 master 和 model，数据和日志文件在同一个驱动器（E 驱动器）中，而对于 tempdb 和 msdb，数据在 E 驱动器和日志中文件在 G 驱动器中，不确定这是否相关。

当作业触发或任何事件被触发时，是否有任何检查系统数据库的顺序？如果该驱动器出现问题，则 msdb 也在同一驱动器上。

这是一个集群服务器，数据库驱动器在两台服务器中共享，服务器用于共享点应用程序。

Server Version: Windows Server 2012 Standard
SQL Server: Microsoft SQL Server 2012 (SP4-GDR) (KB4057116) - 11.0.7462.6 (X64) 
    Jan  5 2018 22:11:56 
    Copyright (c) Microsoft Corporation
    Standard Edition (64-bit) on Windows NT 6.2 …

在本地，我们在READ_COMMITTED隔离级别下使用 SQL Server 2019 标准版，我想测试一个数据库的执行情况READ_COMMITTED_SNAPSHOT（Azure 默认值）。

查询存储已启用。

我想记录READ_COMMITED一周的一些指标（CPU 使用情况、tempdb 使用情况、IO），然后使用READ_COMMITTED_SNAPSHOT. 然后，如果性能更好（这是我所期望的），则计划如何（如果）扩展资源以激活所有数据库的隔离级别。

我们有记录 CPU 使用情况的工具，但没有记录 tempdb 的工具。我想知道是否有一个查询或实用程序可以用来获取当前 tempdb 使用情况（例如给定时刻的 20-50-70%）并创建此类日志？

我对 tempdb 很感兴趣，因为行版本将存储在那里，并且我担心一些遗留代码和繁重/长时间运行的更新，我可能需要首先重写这些更新才能切换隔离级别。

我正在寻找这些数据，因为有很多遗留代码执行速度很慢并且会阻止其他查询。我有以毫秒为单位执行的新代码，但有时，由于长时间运行的 CRUD 操作和阻塞，它会执行 25 秒以上，这很糟糕。我正在重写此类遗留代码，但有时特定情况会花费我几天的时间，有时甚至几个月。当然，客户不愿意等待......

我有以下问题，我的 TempDB 知识还没有涵盖这一点：

• 在 SSMS 中运行约 200 毫秒的分析查询，从应用程序启动时在 SQL Server 上继续运行 60 秒以上 - 这种情况只是偶尔发生，大多数时候问题并不存在
• 可运行/挂起查询的队列可能会增长到同一查询文本的数十个查询，其中一个 SELECT 查询是阻止其他相同 SELECT 的头阻塞程序
• 当可运行/挂起队列与基线相比开始显着增长时，对于相同文本和参数值的特定查询，最主要的等待是 SOS_SCHEDULER_YIELD 和 PAGELATCH_UP
• 当问题发生时，排队的数十个查询具有相同的文字参数值（轮班开始时间戳、员工 ID 和生产区域）
• 被挂起的查询（在我们的监控快照期间 - DBA Dash）将 PAGELATCH_UP 等待作为最主要的等待，并且它们正在等待 tempdb 中的 GAM 页面
• 当我使用在可运行/挂起队列中不断堆积的查询参数检查 SSMS 中的执行计划时，查询不会溢出到 tempdb

服务器、数据库和数据库流量的配置：

• 4 到 6 个核心（问题独立发生在具有不同核心数的两台不同服务器上）
• 4 - 6 个大小统一的 TempDB 文件
• 分配给实例的 40GB RAM
• 在特定数据库中，启用了 RCSI + 快照（因此 TempDB 受到攻击）
• 运行查询的两个表上没有发生删除，只有 INSERT 和 SELECT - 当时仅插入 1 行
• SELECT 通常会命中最年轻的记录（最近插入的记录）
• 服务器通常每秒处理 400 - 700 个批量请求；当问题出现时，与正常操作相比，它会达到峰值 1500，从而产生较高的 IO + CPU …