问题标签 [tempdb]

我在 SQL Server 2008 R2 机器上。

根据 SQL Server，我的TempDB样子是这样的：

这很好......除了我有 2 个Tempdb文件：Tempdb.mdf和Tempdb2.mdf.

我在 中的任何地方都找不到它sys.masterdatafiles，我无法在 Windows 中删除它——因为它说 Windows 正在使用它，并且当第一个tempdb文件增长时，它也会增长，所以我知道 SQL Server 正在使用它。

如何在 SQL Server 中找到此文件，以便将其从使用中删除？

在 SQL Server 2008 中，我试图批量插入大小约为 1GB 的 CSV。当我这样做时，它正在创建一个巨大的 tempdb.mdf 文件。现在，这个 1GB 的 CSV 文件是 35GB。

我已经尝试过微软提供的各种解决方案，但它们似乎都不起作用。

我认为在非生产系统上“缩小” tempdb.mdf 文件的最简单方法是在 SQL 服务关闭时将其删除。

这会导致任何问题吗？如果是这样，可以预期什么样的问题？

编辑

1）这是CSV中的一行（它有大约4M行）：

2）这是数据库描述表信息（没有异国情调，也没有触发器）：https ://gist.github.com/mlissner/4cd13db5a1bbae91dd50

3)我已将数据库设置为简单恢复模式。

我的实例的 tempdb 变得巨大，耗尽了所有可用的磁盘空间并导致应用程序宕机。不得不在紧急情况下重新启动实例。但是，我想调查并深入了解导致临时数据库突然变大的原因。导致这种情况的查询和流程是什么？有人可以帮我提取所需的信息。我知道我不会从 SQL serevr 获得太多历史数据。我确实部署了 Idera SQL 诊断管理器（第三方工具）。任何使用该工具的帮助将不胜感激。

我们正在使用 VM 在 Azure 云中设置 SQL 服务器。当我们确定数据/日志/临时数据库的最佳设置时，我们遇到了许多建议将临时数据库放置在 Azure 提供的临时存储驱动器上的博客文章。然而，更深入的研究从微软那里发现了这一信息，据说不应该这样做。

所以我们留下了以下问题：

• 任何人都可以就我们是否应该将 tempdb 放在临时存储上提供当前的结束答案吗？
• 有人对此事有明确的绩效结果吗？
• 如果将 tempdb 放在临时存储上，可能会产生哪些副作用？

我在下面有一个查询，可以在 SQL Server 中选择一列中的值与另一列中的值之间的差异，但源表中的前两行。源表有三列（PK bigint、Pv float、Cash float）。

当我使用这个查询时，我得到的是一系列单行行集，而不是一个大行集。我可以将这些一个接一个地插入到一个临时表中，然后从中选择，但这意味着对于大型表，我最终会得到一个很大的临时表以及返回第一条记录的长时间延迟。

有没有办法将这个查询的结果作为一个单行集有效地后台处理？

我在 SQL Server 2008r2 中运行查询，它被卡住了

任务状态：暂停（有时更改为正在运行，但主要是暂停）

等待类型：IO_Completion。

同时在 tempdb 上运行另一个查询。

有没有办法解决这个问题？

谢谢

在我当前的项目中，我们提出了一个问题，将 tempdb 的日志文件放在哪里。通常，我们将数据文件和日志文件放在 t:\tempdb 等文件夹中的专用驱动器上。

在一台服务器上，我们将 tempdb 日志放在用户用户数据库的日志文件夹中。

是否有关于将临时数据库的日志文件放在何处的最佳做法？

将它与 tempdb 数据文件或用户日志文件保存在一起是好是坏？

谢谢！

拥有一个 16 核和 200+ GB 内存的专用数据库服务器。

经常使用 tempdb，但它通常保持在 4 GB 以下

最近为 tempdb 添加了一个专用的 SSD 条带

基于这个页面应该创建多个文件

优化 tempdb 性能

了解多行文件。

这是我的问题：
我还应该创建多个 tempdb 日志文件吗？

它确实说“为每个 CPU 创建一个数据文件”。
所以我的想法是数据意味着行（不是日志）文件。

Microsoft SQL Server 2008 R2 (SP1) - Windows NT 6.1 上的 10.50.2500.0 (X64) 企业版（64 位）（内部版本 7601：Service Pack 1）

数以百万计的服务代理对话未正确清理，最终在 tempdb 内部对象中使用了超过 10GB 的空间。

BRKR 任务 task_internal_objects_alloc_page_count：2142768

使用 END CONVERSATION WITH CLEANUP 清理它们后，对话已从 sys.conversation_endpoints 中消失，但 tempdb 中的空间尚未释放。

我希望一些垃圾清理会开始，但空间仍然分配给 8 小时后的内部任务。

关于释放这个空间的任何提示？

（莱姆斯·雷萨努，救命！）

好的。这是我尝试运行的内容：

这是“让我成为数字表”的查询之一。

这就是问题所在。如果我在 SQL Server 服务（重新）启动后立即运行它，则需要很长时间。不像十秒钟那样永远，我希望它更快。永远一样，我一次不小心让它超过了两个小时，仍然不得不杀死它。我想它永远不会回来。通常在我的机器上运行它需要不到两秒钟的时间。

但是，如果我这样做：

然后它会像您期望的那样工作——第一个SELECT运行不到两秒钟，第二个也是。为什么我不直接使用三表版本？因为没有足够的条目sys.objects使该数字立方等于一百万个结果行。但这已经不是重点了。

不管怎样，从现在开始，我可以重复那一秒DROP/SELECT…INTO我想要的次数，没问题。不知何故，第一个三表版本让它永远没问题。至少，直到下一次服务重新启动和/或机器重新启动。在这一点上，再次运行最后SELECT一次永远不会回来。再次。

这就是它开始变得更加奇怪的地方。如果我先将其SELECT还原为两表版本：

这也使得第二次SELECT运行永远。 单表版本也是如此。不知何故，那个三桌版本很神奇！

这里发生了什么？为什么这么慢？

（在有人指出我正在创建一个永久表之前tempdb，是的，我知道。更改为实际的临时表没有任何区别。）

添加信息：

• 这是 SQL Server 2012 开发者版
• EXEC sp_WhoIsActive @find_block_leaders = 1, @sort_order = '[blocked_session_count] DESC'（脚本为 XML，因此可以在此处阅读）的输出是：

更多补充信息：

为什么我把它放在 tempdb 中是因为它是旨在在原始安装上运行的脚本的一部分，并且 tempdb 保证在那里。正如我所说，更改为全局临时表并没有什么不同。