服务热线：
发布时间： 2024-02-28 14:51:51 来源：电竞比分-存储调理
在我之前关于SQLServer 系统数据库的文章中，我们不难发现了作为SQLServer 安装一部分的每个系统数据库。当前文章将重点介绍围绕
正如该系统数据库的名称所示，tempdb保存由SQLServer 创建的临时对象。它们与多个操作相关，并充当连接到SQLServer 实例的全用户的全局工作区。
临时对象是由用户明确创建的。它们能是本地或全局临时表和索引、表变量、表值函数中使用的表和游标。
支持行版本控制功能的版本存储，通用版本存储或在线索引构建版本存储使用tempdb数据库文件。
每次SQLServer 服务启动时都会创建Tempdb数据库。因此，可以将tempdb数据库创建时间视为SQLServer 服务启动时间的近似值。我们大家可以使用下面显示的查询从sys.databasesDMV 中识别它：
但是，SQLServer Service的实际启动涉及以特定顺序启动所有系统数据库。它可能发生得比tempdb创建时间早一点。我们可以通过在sys.dm_os_sys_infoDMV上执行以下查询，使用sys.databasesDMV获取值。
我们可以在SQLServer 错误日志中找到有关启动SQLServer 服务时启动的数据库顺序的更多信息。
我们可以看到，在启动SQLServer 服务时，master数据库已经先启动了。然后是所有用户数据库和所有其他系统数据库。最后，tempdb启动。您还可以通过执行xp_readerrorlog系统过程以编程方式获取此信息：
注意：如果SQLServer 服务最近没有重新启动，并且SQLServer错误日志被回收，这可能会将较旧的错误日志推送到较旧的文件，则上述两种方法可能都不会显示必要的信息。在这种情况下，我们可能需要扫描存档的SQLServer 错误日志文件中的数据。
由于tempdb为所有用户会话或活动提供了一个全局工作区，如果不仔细配置，它可能成为用户操作的性能瓶颈。在我之前的文章中，我们讨论了在tempdb数据库中实施的推荐最佳实践。但是，即使在实施它们之后，我们也可能经常遇到问题：
从SQLServer 2000 开始，默认建议是根据服务器中可用的逻辑核心数拥有多个数据文件。
如果其中一个文件大小由于某种原因无法自动增长，则会导致某些文件与其他文件相比变得非常大。这会导致对大文件造成额外过载，并对tempdb数据库产生负面性能影响。
我们需要手动确保所有tempdb数据文件在任何时间点手动均匀大小以避免争用或性能问题，直到SQLServer 2014。从SQLServer 2016开始及之后的版本，Microsoft通过实现一些功能改变了这种行为，这些将在本文后面讨论。
为了克服上述性能问题，SQLServer 引入了2个名为1117和1118的跟踪标志以避免围绕tempdb的争用问题。
如果没有启用跟踪标志1117，每当tempdb配置有多个均匀大小的数据文件并且数据文件需要自动增长时，默认情况下SQLServer 将尝试以循环方式增加文件大小（如果所有文件）。如果数据文件的大小不均匀，则SQLServer 将尝试增加tempdb的最大数据文件的大小，并将使用这个较大的文件进行大多数用户操作，从而导致tempdb争用问题。
为了解决这个问题，SQLServer 引入了TraceFlag 1117。一旦启用，如果文件组中的一个文件需要自动增长，它将自动增长该文件组中的所有文件。它解决了tempdb争用问题。但是，问题是一旦启用了跟踪标志1117，就会为所有用户数据库配置自动增长。
Extent是一组8个物理上连续的页面，大小为64KB(8*8KB)。根据Extent中存储数据的对象或所有者的数量，Extent可以分为：
UniformExtents是由单个对象或所有者使用或访问的8个连续页面；
MixedExtents – 8 个连续页面被最少2个和最多8个对象或所有者使用或访问
启用跟踪标志1118将允许tempdb具有统一的范围，从而获得更好的性能。
即使在SQL服务重新启动后也永久可用。推荐的方法是通过SQLServer 服务启动参数启用TraceFlags 1117 和1118。
全局启用跟踪标志。SQLServer 服务将在服务重新启动时丢失跟踪标志。要全局启用跟踪标志，请在新的查询窗口中执行以下脚本：
在会话级别启用跟踪标志。它仅适用于用户创建的当前会话。要在会话级别启用跟踪标志，请在新查询窗口中执行以下脚本：
要查看在SQLServer 实例中启用的跟踪标志列表，我们能够正常的使用DBCCTRACESTATUS命令：
正如我们所见，跟踪标志1117和1118在我的实例中与Session一起全局启用。
但是，根据我的个人经验，最好将tempdb预先增长到一个巨大的大小，以避免多次自动增长的需要，并消除不均匀的文件大小或SQLServer 广泛使用的单个文件。
设置文件组内所有文件的自动增长的跟踪标志1117现在是文件组的属性。我们大家可以在创建新文件组或修改现有文件组时对其进行配置。
要修改AdventureWorks数据库的主文件组的自动增长属性，我们使用AUTOGROW_ALL_FILES执行以下脚本以平均自动增长所有文件或使用AUTOGROW_SINGLE_FILE仅允许自动增长单个数据文件。
默认情况下，为tempdb和从SQLServer 2016 开始的全用户数据库启用设置数据文件的统一范围属性的跟踪标志1118。我们无法更改tempdb的属性，因为它现在仅支持UniformExtent 选项。
对于用户数据库，我们可以修改这个参数。默认情况下，系统数据库master、model和msdb支持混合范围，并且也不能更改。
在SQLServer2014或更早的版本中，如果没有将跟踪标志1117和1118与tempdb数据库创建的多个数据文件正确配置，其中一些文件将不可避免地变大。如果发生这种情况，DBA通常会尝试缩小tempdb数据文件。但这是一个处理这种情况不恰当的方法。
让我们考虑可用于Shrinktempdb 的DBCC命令以及执行这些操作的影响。
该DBCCSHRINKDATABASE控制台命令是通过缩小数据日志文件的末尾。
要成功收缩数据库，该命令需要文件末尾的可用空间。如果文件末尾有任何活动事务，则无法缩小数据库文件。
执行DBCCSHRINKDATABASE的影响是它会尝试清除每个数据文件或日志文件末尾的可用空间，这些空间可能已为表数据的未来增长保留。因此，运行此命令可能会导致文件大小不均匀，从而导致tempdb争用问题。
该DBCCSHRINKFILE控制台命令的工作原理类似DBCCSHRINKDATABASE，但它缩小了指定的数据库数据或日志文件。
如果您发现某个特定的tempdb数据文件很大，我们可以尝试使用DBCCSHRINKFILE 缩小该特定项目，如下所示。
在tempdb上使用此命令时要小心，因为如果文件收缩到低于或高于其他数据文件的值，则该特定数据文件将无法有效使用。或者，它会被更频繁地使用，从而导致tempdb争用问题。
该DBCCFREEPROCCACHE命令清除所有的存储过程的执行计划缓存。
SQLServer 使用过程执行计划缓存来更快地执行相同的过程调用。执行DBCCFREEPROCCACHE 后，PlanCache 被清除。因此，当在实例中执行存储过程时，SQLServer 必须再次创建该缓存。在生产数据库实例中执行时会留下严重的负面影响。
该DBCCFREESESSIONCACHE命令将清除SQLServer实例的分布查询连接缓存。当在特定SQLServer 实例上执行许多分布式查询时，这将很有帮助。
该DBCCFREESYSTEMCACHE命令清除所有缓存中的所有未使用的缓存条目。默认情况下，SQLServer 这样做是为了让更多内存可用于新操作。但是，我们可以使用以下命令手动执行它：
.众所周知，tempdb存储所有临时用户对象或内部对象，包括执行计划缓存、缓冲池数据、会话缓存和系统缓存。因此，执行上述6条DBCC命令将有助于清除阻止正常收缩过程的tempdb数据文件。
尽管我们已经通过各种方法完成了如何缩小tempdb的步骤，但下面列出了处理tempdb数据库的推荐最佳实践：
A.如果可能，重新再启动SQLServer 服务以均匀地重新创建tempdb数据文件。潜在的影响是，我们将丢失上面讨论的所有执行计划和其他缓存信息。
B.将tempdb数据文件预增长到保存tempdb数据文件的驱动器中可用的巨大文件大小。这将防止SQLServer 在SQLServer 2014 及更早版本中不均匀地增加文件大小。
如果由于RTO或RPO导致SQLServer 服务无法重新再启动，请在清楚了解影响后尝试上述DBCC命令。
D.收缩tempdb数据库或数据文件不是推荐的方法，因此永远不要在您的生产环境中这样做，除非没有其他选择。
我们已经了解了有关tempdb工作原理的更多信息，以便我们大家可以配置tempdb以获得更好的性能，从而避免tempdb上的争用问题。我们还讨论了tempdb中经常遇到的问题、SQLServer 中跨各种版本的可用措施以及如何有效地处理它。除此之外，我们还研究了为什么在处理tempdb数据库时不推荐使用收缩tempdb数据库或数据文件的方法。
