问题标签 [tempdb]

SQL Server 抱怨它什么都没有，我想这比充满其他东西要好。这个问题有一些非常有趣的答案，尤其是 Steven 的答案。

但是，在运行他提供的脚本后，我没有看到 TRANSACTION 或 BACKUP 作为 log_reuse_wait_description 列中的条目，而是只看到“NOTHING”和“CHECKPOINT”每个“state_desc”值都是“ONLINE”，每个“recovery_model_desc”都是“SIMPLE” ”。所有“最后一次完整备份”的值都是相同的 - 2014 年 10 月 31 日 - 差不多一年半前。

我很长一段时间都不是 DBAdmin，所以不知道这些东西是什么意思，或者最重要的是，不知道如何防止错误消息的发生。

我可以从 C# 方面做些什么来防止这种“没有任何东西”的错误发生吗？

整个错误消息是：

日期：2016 年 3 月 7 日下午 2:24:45 消息：2016 年 3 月 7 日，星期一：异常消息：数据库“tempdb”的事务日志已满，因为“没有”。异常源：.Net SqlClient 数据提供程序异常 StackTrace：在 System.Data.SqlClient.SqlConnection.OnError（SqlException 异常，布尔 breakConnection，Action1 wrapCloseInAction) at System.Data.SqlClient.SqlInternalConnection.OnError(SqlException exception, Boolean breakConnection, Action1 wrapCloseInAction) 在 System.Data.SqlClient.TdsParser.ThrowExceptionAndWarning(TdsParserStateObject stateObj, Boolean callerHasConnectionLock, Boolean asyncClose) 在 System.Data.SqlClient.TdsParser.TryRun(RunBehavior runBehavior, SqlCommand cmdHandler, SqlDataReader dataStream, BulkCopySimpleResultSet bulkCopyHandler, TdsParserStateObject state&Obj, Boolean dataReady) 在 System.Data.SqlClient.SqlDataReader.TryConsumeMetaData() 在 System.Data.SqlClient.SqlDataReader.get_MetaData() 在 System.Data.SqlClient.SqlCommand.FinishExecuteReader(SqlDataReader ds, RunBehavior runBehavior, String resetOptionsString) 在 System.Data .SqlClient.SqlCommand.RunExecuteReaderTds(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, Boolean async, Int32 timeout, Task& task, Boolean asyncWrite,System.Data.SqlClient.SqlCommand.RunExecuteReader 的 SqlDataReader ds，布尔 describeParameterEncryptionRequest）（CommandBehavior cmdBehavior，RunBehavior runBehavior，布尔 returnStream，String 方法，TaskCompletionSource`1 完成，Int32 超时，任务和任务，布尔 asyncWrite）在 System.Data.SqlClient。 SqlCommand.RunExecuteReader(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, String method) 在 System.Data.SqlClient.SqlCommand.ExecuteReader(CommandBehavior 行为, String 方法) 在 System.Data.SqlClient.SqlCommand.ExecuteDbDataReader(CommandBehavior 行为) 在 System. Data.Common.DbCommand.System.Data.IDbCommand.ExecuteReader（CommandBehavior 行为）在 System.Data.Common.DbDataAdapter.FillInternal（DataSet 数据集，DataTable[] 数据表，Int32 startRecord、Int32 maxRecords、String srcTable、IDbCommand 命令、CommandBehavior 行为）在 System.Data.Common.DbDataAdapter.Fill（DataSet dataSet、Int32 startRecord、Int32 maxRecords、String srcTable、IDbCommand 命令、CommandBehavior 行为）在 System.Data.Common .DbDataAdapter.Fill(DataSet dataSet) at ReportRunner.SharedCode.SQLDBHelper.ExecuteSQLReturnDataTable(String sql, CommandType cmdType, SqlParameter[] 参数)ExecuteSQLReturnDataTable(String sql, CommandType cmdType, SqlParameter[] 参数)ExecuteSQLReturnDataTable(String sql, CommandType cmdType, SqlParameter[] 参数)

因此，该 msg 中引用的我的代码是 ExecuteSQLReturnDataTable()，即：

那么我可以在这段代码中添加什么来缓解甚至消除问题吗？

TempDB每次重新启动服务器时，SQL Server 是否都会为数据库重新创建主文件和辅助文件？或者它只是在每次服务器重新启动时刷新.mdf,或日志文件？.ndf

目前，我有一些临时表，格式为“#A0089D2C”、“#A0232241”

我如何选择它们以查看其数据是什么？

我尝试了以下这些查询：

但我得到了错误：

请指教。

谢谢。

虽然我从这篇文章中获得了一些进一步的见解，但我仍在努力更全面地了解我最近对变量表的使用以及相关的 tempdb 增长。

我最近一直在存储过程和表值函数中使用变量表。我对变量表 v 的本地/全局临时表的使用是可能影响我正在经历的更大挑战的一个领域。

由于使用这种类型的临时表，tempdb 已经增长到大约 50+GB 区域，并且在使用exec sp_spaceused @updateusage=true我正在查看的检查表时：database_size: 51935.13MB unallocated_space: 51908.80MB并且在检查数据库的内容时，不存在临时表或系统表。对于 ref tempdb.ldf 非常小。

在使用检查我的会话使用情况时，exec sp_who我还看到多行指示睡眠，我怀疑这可能是我们遇到连接未正确关闭的问题。

从阅读各种帖子和 SO 来看，普遍的共识是不要尝试缩小 tempdb 和相关文件，事实上，我更愿意解决根本问题，而不是转向更碎片化的数据存储。

关于为什么我现有的方法可能会影响 tempdb 增长以及使用本地/全局临时表是否更合适，是否有任何建议。

关于 tempdb 它是自身的，虽然存储很便宜，但我需要确保包含这种增长，因此任何有关维护的建议（将数据库拆分为多个文件、可能的缩小、将数据库移动到单独的驱动器）等都将不胜感激。

如果没有足够的 tempdb 可用，我想以一种返回错误消息的方式运行我的大部分查询。

有没有办法做到这一点？

等待 tempdb 有更多空间的默认行为。但这是没用的，因为如果其他进程同时使用 tempdb，它们会相互死锁。

我正面临着确切的 问题，并考虑尝试提出的解决方案。

我想知道如何查询最大大小的表，TempDB或者是否有一个查询列出了 tempdb 中具有相应大小的所有表

我读了这篇文章 https://azure.microsoft.com/en-us/documentation/articles/virtual-machines-windows-sql-performance/

这解释了在 Azure 中申请提高 SQL 服务器性能的最佳实践，我有一个带有临时磁盘 SSD 的 DS_v2 虚拟机（然后每次重新启动都会擦除所有数据），有人可以说我在这个临时存储 tempdb 是否有任何问题分割？这种做法的一些优点和缺点？

谢谢！安德烈

在我们的 SQL Server 代理上，一项工作通常每天需要 30 分钟才能完成。今天，它运行了 3 小时 41 分钟，然后由于 “无法为数据库 'tempdb' 中的对象 'dbo.SORT 临时运行存储：140907480547328' 分配空间，因为 'PRIMARY' 文件组已满”而失败

现在我知道 tempdb 已满且作业失败。但是该作业设置为再进行 2 次尝试，并且在第二次尝试时，该作业在 31 分钟内完成，没有出现此失败。

我关于这个问题的问题是：

1）为什么第二次没有失败？

2）如果它在第一次尝试时空间不足，为什么它通常在 31 分钟内完成时要等待 4 小时才能完成？

围绕这些问题的任何想法都会非常有帮助。

谢谢，R。

再会，

是否可以更改我当前会话使用的 tempdb？我有一个非常繁重的查询，用于 HD 使用。理想情况下，我希望使用我们专门用于此类繁重事物的 tempdb 运行查询。（主要问题是查询创建了一个非常大的临时表）

我想要一些类似的东西：

如果这是可能的，即使通过其他方式，请告诉我。现在，我知道的唯一方法是将用户绑定到不同的 tempdb，然后使用该用户而不是普通用户进行 HD 登录。

在此先感谢，ziv。

我们注意到温度已经填满了放置它的驱动器。它发生在两天前，有没有办法找到导致temp do增长的SQL。SQL 失败，因为它已经填满了 250GB 驱动器，无法获得更多空间。