标签: tempdb

继我最近在 Tempdb 上提出的一个问题之后。我想知道在添加和移动 tempdb 文件时如何正确设置自动增长属性？

我问这个问题是因为我想让 SQL Server 使用循环算法将工作负载分散到每个文件上。据我了解，如果文件大小不相等，那么 SQL Server 将使用空间最大的文件，从而增加导致闩锁争用的机会。我这里的理解正确吗？

干杯，

我们在 S3 层上运行 V12 Azure 数据库实例。数据库上仍有大约 100GB 的可用空间。当使用在不同的非 azure SQL 服务器上运行的 SSIS 加载 85MB XML 文件，并将其直接插入到 azure 数据库中时，插入会在目标数据库上崩溃，并出现以下错误。

数据库“tempdb”已达到其大小配额。对数据进行分区或删除、删除索引或查阅文档以获取可能的解决方案。

tempdb 是否有任何限制或者知道为什么这可能会崩溃？85MB 的文件不可能填满数据库的剩余空间。似乎tempdb隐藏起来了，我如何监控它的使用情况？

根据最佳实践，建议将所有tempdb（不仅仅是 tempdb）文件移动到不同的物理磁盘中。

我有一个虚拟服务器，最初有来自同一RAID 10池的 4 个 LUN。在卷管理器的帮助下，我将这 4 个 LUN 转换为 4 个不同的卷。

现在的问题是，移动tempdb到单独的卷中是否会产生任何影响，或者就性能而言，将它们与其他 SQL Server 文件保留在一起就可以了？

我有一个无法杀死的顽固 spid，它阻止了我的 tempdb的事务日志被截断

这就是我发现这个流氓 spid 的方法：

if object_id('tempdb..#OpenTranStatus','U') is not null
   drop table #OpenTranStatus

CREATE TABLE #OpenTranStatus (
ActiveTransaction varchar(25),
Details sql_variant
);
 
-- Execute the command, putting the results in the table.
INSERT INTO #OpenTranStatus
EXEC ('DBCC OPENTRAN (sqlwatch) with tableresults')
SELECT * FROM #OpenTranStatus

这是它正在运行（或保留）的查询：

select d.database_id , sd.sqlwatch_database_id, sd.sql_instance
        into #d
        from dbo.vw_sqlwatch_sys_databases d

        inner join [dbo].[sqlwatch_meta_database] sd 
            on sd.[database_name] = d.[name] collate database_default
            and sd.[database_create_date] = case when d.name = 'tempdb' …

我想就我们的 SQL Server 2005 TempDB 的最佳设置获得建议。

目前，我们的临时数据库由MDF3 GB 的单个文件和 120 MB 的单个日志文件组成，位于 3 轴 RAID-5 阵列的 D: 驱动器上，该阵列被分区为 C: 和 D: 驱动器。D: 驱动器还包含我们的应用程序核心程序和我们的报告数据库。

我想将临时数据库移动到它自己的驱动器，它是一个带有单个分区的 2 轴 RAID-1 阵列，驱动器 F:。

MDF当我将它移动到这个驱动器时，我想创建 4 x 1 GB 的临时数据库文件。我没有另一个备用的专用驱动器来拆分 TempDB MDF 和 LDF 文件，因此两者都必须在同一个驱动器上。

我应该将 LDF 文件留在当前驱动器上还是应该将所有文件移动到新驱动器上？

我有一个包含约 100 个数据库的环境，所有数据库都具有相同的架构。每个数据库上都有一个存储过程，它创建一个#temp 表并删除它，并且运行非常频繁（每个用户每 30 秒左右，并且有 1000 多个用户）。它的作用远不止于此：我们正在将潜在的数千行加载到这个临时表中，然后将整个内容转储出来，基本上它聚合了一堆数据。

由于所有数据库都创建相同的临时表，它们是否都相互竞争？还是每个数据库都在 tempdb 中获得了自己的临时表版本？

似乎他们有争用，因为我看到大量PAGE_LATCH等待，都在 tempdb ( 2:3:1041580)的同一页面上，这不是 GAM、SGAM 或 PFS 页面，并且 90% 的等待似乎来自同一个页面跨所有数据库的存储过程。这些等待占服务器总等待的 90%，并导致阻塞。

我做了一个DBCC PAGE，它似乎是sysobjvalues（来自标题中的 object_ID 60）。我跑了：

SELECT OBJECT_Name(object_ID), * 
FROM sys.dm_db_database_page_allocations(2,60,NULL,NULL,'DETAILED')

我得到 153 行，不确定我在这里看到的是什么。看起来像它IN_ROW_DATA和LOB_DATA在allocation_unit_type_desc。

我在与其他文件不同的卷上有 8 个 tempdb 文件。我有 16 个内核，但我的理解是，由于它不是分配页面，因此可能无助于增加文件数量。使用 SQL Server 2017 企业版。

我觉得最好的办法是告诉开发人员在这里删除临时表，但这需要重新处理逻辑并且需要一些时间。在等待开发修复时，我还能做些什么来避免这些页面闩锁？

添加 Tempdb 文件是否需要重新启动？我们想在同一个驱动器上添加文件，不删除和不修改。我们在 Dev 和 QA 环境中进行了测试，不需要重启。但是对于生产，我想确保一切正常。有些是陈述条件，并不总是必要的，有时是必要的，我正在阅读以下资源：

ALTER DATABASE [tempdb] ADD FILE ( NAME = N'tempdev2', FILENAME = N'G:\tempdb2.ndf' , SIZE = 12288000KB , MAXSIZE = UNLIMITED, FILEGROWTH = 0 )
GO
ALTER DATABASE [tempdb] ADD FILE ( NAME = N'tempdev3', FILENAME = N'G:\tempdb3.ndf' , SIZE = 12288000KB , MAXSIZE = UNLIMITED, FILEGROWTH = 0 

您是否需要中断才能添加 tempdb 文件？Brent Ozar https://www.brentozar.com/blitz/tempdb-data-files/ “从技术上讲，并非总是如此。但实际上，是的。如果必须缩小文件，在使用 SQL Server 时这非常困难，并且我们已经看到，在添加文件后重新启动 SQL Server 之前，防病毒/文件控制工具才起作用。”

http://jackworthen.com/2017/08/24/adding-additional-data-files-to-the-tempdb-database-in-sql-server/ “一旦创建了附加文件，并不总是需要执行服务重启。但是，在许多生产环境中，如果不先重启服务，就不可能简单地修改现有 TempDB 数据文件 (tempdev) 的文件大小。”

以下资源表示无需重启：https : //www.codykonior.com/2015/08/10/modifying-tempdb-database-files-without-a-restart/ http://jackworthen.com/2017/08 /24/adding-additional-data-files-to-the-tempdb-database-in-sql-server/

在我们的 SQL Server 生产环境中，一些用户运行临时查询，将大量数据提取到 tempdb 中并将其填满，从而导致生产服务器出现问题。当这些报告/查询从前端运行时，它们有时会弄乱将数百万行拉到临时表的日期范围。是的，用户需要接受教育，也需要调整，我们已经这样做了，但他们仍然偶尔会产生问题。

现在他们说在 SAP ASE (Sybase) 中有一个功能可以创建多个 tempdb 和重定向用户并限制使用，通过不膨胀单个 tempdb（就像在 SQL Server 中一样）并使服务器停机。

我们在 SQL Server 中有这样的东西吗？

为一个查询的两次执行捕获了两个实际的查询计划：

计划“快速”花费了大约 1 秒，大约 90% 的时间都会发生。

计划“慢”花了大约 16 秒。

由于图形计划看起来与我相同，因此我转储了 XML 版本并执行了差异以查看文本差异以确保。

快侧有 2 个“SpillToTempDb”警告，慢侧有 4 个警告。看着 2 个额外的慢端：

One SpillToTempDb warning on "Parallelism (Repartition Streams) Cost 1%":

    <SpillToTempDb SpillLevel="0" />

On SpillToTempDb warning on "Parallelism (Distribute Streams) Cost 1%":

    <SpillToTempDb SpillLevel="0" />

慢速和快速情况下的成本是相同的 (1%)。这是否意味着可以忽略警告？有没有办法显示“实际”时间或成本。那会好很多！对于溢出操作，实际行数是相同的。

除了执行 xml 执行计划的手动文本差异以查找警告中的差异之外，我怎么知道运行时间增加 1500% 的实际原因是什么？

除了“RunTimeCountersPerThread”行之外的差异：

Left file: C:\Users\chrisr\Desktop\fast.sqlplan     Right file: C:\Users\chrisr\Desktop\slow.sqlplan
10                    <ThreadStat Branches="10" UsedThreads="85">
     10               <ThreadStat Branches="10" UsedThreads="73">
------------------------------------------------------------------------
------------------------------------------------------------------------
19                    <MemoryGrantInfo SerialRequiredMemory="1536" SerialDesiredMemory="10816" RequiredMemory="124224" DesiredMemory="133536" RequestedMemory="133536" GrantWaitTime="0" GrantedMemory="133536" MaxUsedMemory="105440" />
     19               <MemoryGrantInfo …

SQL Server 在名为tempdb 的数据库中工作以处理大量任务。连接和聚合等查询操作发生在那里。在线索引重建、排序依据、聚合函数、触发器也在tempdb 中完成。

如何衡量何时应该添加另一个 tempdb 数据文件？需要多少个 tempdb 数据文件？