【发布时间】：2011-03-11 02:21:33
【问题描述】：
我们使用的是 SQL Server 2005。由于 tempdb 大小过大，最近 SQL Server 2005 在我们的生产环境中崩溃了。 1) 大 tempdb 大小可能是什么原因？ 2) 有什么方法可以查看 tempdb 中有哪些数据？
【问题讨论】：
-
添加了一些更相关的标签。
标签： sql-server sql-server-2005 tempdb
【发布时间】：2011-03-11 02:21:33
【问题描述】：
2) 有什么方法可以查看 tempdb 中有哪些数据？
不，因为它没有保存在那里。 Tempdb 有非常特殊的处理，例如在每次服务器重启时被丢弃。
1) 大 tempdb 大小可能是什么原因？
低效的 SQL、维护工作或手头的数据。显然，一个 800gb、6000gb 的数据库可能需要比 4gb 在线 crm 尝试更多的 tempdb 空间。您并没有真正以绝对值指定任何大小。什么是大的？我在较小的服务器上硬编码了 64gb 的 tempdb 数据库。
进入 Tempdb 的典型 SQL 是：
- 作为查询的一部分无法解决的排序（您需要在某些地方存储键）
- 不同。需要 tempdb 中的所有返回数据来查找双精度数。
- 可能在连接期间执行某些操作。
- Tempdb 使用情况（临时表）。我之所以提到它们，是因为我在加载和清理期间经常在其中保留数百兆字节的数据。
一般而言，您可以通过在查询日志中包含大量 IO 统计信息来找到这些查询，或者只是速度较慢。
也就是说，维护计划也存在，但有理由。最后，您的“大”可能是我的“甚至不值得一提的小”。这真的取决于你做什么。使用查询跟踪工具找出需要花费的时间。
在物理上 Tempdb 在处理上非常特殊 - 如果不需要，sql server 不会写入文件（即，将 thigns 保存在内存中）。写入磁盘是内存流动的标志。这与正常的数据库写入行为不同。如果 Tempdb 溢出，最好放在速度相当快的 SSD 上……这通常不会那么昂贵，因为它仍然相对较小。
使用此处的查询来查找有关 tempdb 的其他查询 - 基本上您在这里是在脏水里钓鱼，需要尝试一些事情直到找到罪魁祸首。
【讨论】：
增长 SQL Server 数据库（任何数据库，而不仅仅是 tempdb）的常用方法是将其数据和日志文件设置为自动增长（尤其是日志文件）。 SQL Server 非常乐意增加日志和数据文件，直到耗尽所有可用的磁盘空间。
恕我直言，最佳做法是允许对数据文件进行有限的自动增长（设置数据文件可以增长的上限）并修复日志文件的大小。您可能需要进行一些分析以确定日志文件需要多大。特别是对于 tempdb，恢复模式也应该设置为 simple。
【讨论】：
-
通常的方式（对于非专业环境
-
可能你没看懂我说的：他的数据库吞掉了他的硬盘驱动器的原因是因为它被保留在默认（自动增长）配置中。坏主意。
好吧 tempdb 是一个特殊的数据库。您在过程等中使用的任何临时对象都在这里创建。因此，如果您的应用程序在查询中使用了大量临时表，它们都将驻留在此处，但它们应该在连接 (spid) 重置后自行清理。
另一个可以增加 tempdb 的事情是数据库维护任务，但是它们会对数据库日志文件造成更大的损失。
每次重新启动 SQL 服务时也会清除 Tempdb。它基本上删除数据库并重新创建它。我同意@Nic 关于保留 tempdb 的观点，不要乱用它，tempdb 中的任何空间问题通常表明其他地方存在另一个更大的问题。更多的空间会掩盖问题，但只会持续这么长时间。您的驱动器有多少可用空间用于安装 tempdb？
如果还没有，请尝试将 tempdb 放在它自己的驱动器上，如果可能的话，再把数据和日志文件放在它们自己单独的驱动器上。
因此，如果您不重新启动 SQL Server/服务，您的驱动器很快就会耗尽空间。
【讨论】：
使用临时数据库
从 sys.database_files 中选择 (size*8) 作为 FileSizeKB
【讨论】：