jrd*_*dba 12 sql-server tempdb troubleshooting
我试图找出是否可以将 tempdb 文件添加到 SQL Server 而不必重新启动 SQL Server 服务。我在数据库管理员上看到了这个答案：
一个答案指出：
添加 - 无需停机。尽管正如 Microsoft 的 Sean 指出的那样，SQL 更喜欢使用填充较低的文件。如果您要从 1 个数据文件开始并添加更多数据，那么 SQL 将使用新的数据文件一段时间，但您的性能不会比只有一个文件差。但是，如果您已经有 2+ 个并再添加一个，那么它会在新的一个上产生热点并降低性能。
但是，评论警告以下几点：
我会在“添加”部分添加一个附录：“添加：不，但你很可能会不平衡，所以你会成为热点，这可能会使事情变得更糟。”
我对该评论有以下问题，但被指示在我自己的一个新问题（这个问题）中提出这些问题，而不是通过该问题答案中的评论来询问评论者。
具体来说：
Aar*_*and 16
什么是热点？
在这种情况下，“热点”意味着，即使 tempdb 有多个文件，所有 I/O 工作都在一个文件中完成。如果 tempdb 忙到足以证明添加文件是合理的，导致热点（由于比例填充）的不平衡将是短暂的，所以我认为警告可能有点鸡肋。无论如何，以我的经验。
热点如何使 tempdb 中的事情变得更糟？
我认为它在 tempdb 中被认为更糟，因为它在大多数工作负载中首当其冲。您当然会在用户数据库中遇到类似的问题，但是由于您已经在尝试解决 tempdb 中的问题......
数据库中的哪些具体事情会变得更糟？
主要是写时间。想象一下，即使附近还有 7 台其他 ATM，每个人都试图使用同一个 ATM。在任何时间点只能写这么多；其他一切都必须等待。有了更多的文件（和足够的内核来安排工作），I/O 可以更均匀地分布。
只要确保：
Sea*_*ser 10
- 什么是热点？
Aaron 是正确的，我不会重复他上面所说的内容，但这不仅仅是关于磁盘 IO。大多数人在 TempDB 中遇到问题的主要部分是由于对某些跟踪结构的争用。
由于拥有多个 tempdb 文件允许按比例填充和循环算法有效地在分配之间“公平”地发生，因此添加一个没有分配的新文件会有点偏离。我不同意这是一个“小鸡”警告（请参阅下面的产品更新），如果您开始看到PAGELATCH_*对所述新文件的等待而不是在其他文件上等待很多或任何。这通常发生在具有高 TempDB 活动并且已经有多个文件的系统上。
请注意，SQL Server 2019 中有一些选项可以将一些基础系统表更改为内存表，这可能会有所改进，因为内存对象的分配方式与磁盘烘焙表不同。基于磁盘的表是我们多年来一直在使用的传统表。SQL Server 2014 引入了内存优化表。SQL Server 2019 可以处理内存优化表中的一些分配元数据。
SQL Server 2019 中进行了另一项更改以帮助并发 PFS 更改，这通常是分配中内存结构争用的PAGELATCH_*等待。
- 热点如何使 tempdb 中的事情变得更糟？
没什么恕我直言。是的，TempDB 有更多的项目可以在不直接使用的情况下对其进行写入，因此它会阻碍某些项目。然而，就数据变化率而言，一个非常繁忙的用户数据库同样糟糕。它不仅限于 TempDB。
- 数据库中的哪些具体事情会变得更糟？
我真的很喜欢亚伦的比喻！这就是正在发生的事情的本质。真正变得更糟的是数据库中对象的空间分配和跟踪。如果您的用户数据库大部分是静态的（低变化率）或者您的 TempDB 没有真正被使用，您将不会注意到任何事情。但是，如果它是一个相当繁忙的服务器，您可能会启动或加剧 pagelatch 等待，这可能导致车队阻塞。
Aaron 已经指出，在旧版本上有跟踪标志以确保使用统一的范围并且文件组中的所有文件一起增长（Aaron 指出 1117 和 1118 是 2016+ 中的 NOP）。我想再次指出的另一件事是，这不仅适用于 TempDB，而且适用于任何数据库，物理布局应根据需要考虑。
这不仅适用于热点问题，还适用于系统的其他部分，如备份/恢复、文件管理、文件系统元数据碎片等，这些都可以通过拥有多个文件来帮助。
您可以通过waitresource在 PFS 页（即第 1 页，然后每 8088 页）上查找 a 来查看分配结构争用。如果您在同一个文件 (2:file:page) 中看到所有这些，那么您就知道正在发生这种情况。