问题标签 [tempdb]

我计划在一台新机器上全新安装SQL Server 2005，我必须订购。我知道tempdb 调优对 SQL Server 实例的整体性能非常重要。

我读过最好的做法是创建与 CPU（或内核？）一样多的 tempdb 文件。那是对的吗？是否有任何其他建议，例如我应该注意的硬盘/RAID 设置配置？

谢谢！

我们的生产 SQL Server 存在一些问题。

服务器：双四核 Xeon 8 GB RAM 单 RAID 10 阵列 Windows 2003 Server 64 位 SQL Server 2005 标准 64 位

现在机器上有大约 250MB 的可用 RAM。SQL Server 有大约 6GB 的 RAM，而我们的监控软件说只有一半的 SQL Server 分配的 RAM 实际被使用。

我们的主数据库大约为 20GB，其中大约 12GB 用于任何频率。我们的 tempdb 为 700MB。两者都位于同一个物理磁盘阵列上。

此外，使用 Filemon，我能够看到 tempdb 文件有 100 或 1000 次长度为 65536 的写入。磁盘队列长度在近 80% 的情况下超过 100。

所以，这是我的问题-

1. 什么会导致 tempdb 上的所有这些写入？我不确定我们是否一直有这么多活动，但这似乎过度了，而且这些问题是最近才出现的。

2. 我应该向服务器添加更多内存吗？

3. 在高负载服务器上，tempdb 和 db 文件是否应该位于不同的阵列上？

是否有可能在 MS-SQL 中有一个“持久”临时表？我的意思是我目前有一个后台任务，它生成一个全局临时表，它被各种其他任务使用（这就是我将它设为全局的原因）。不幸的是，如果表变得未使用，它会被 SQL 自动删除——这由我的系统优雅地处理，因为它只是将它排队等待再次重建，但理想情况下我希望它每天只构建一次。所以，理想情况下，我可以设置一些超时参数，比如“如果 1 小时内没有任何东西触及这个，那么删除”。

我真的不希望它在我现有的数据库中，因为它会导致与管理数据库（碎片、日志增长等）相关的更多问题，因为它有效地汇总数据，仅在 24 小时内有用，并且占用更多超过 1 GB 的 HD 空间。

最坏的情况是，我的计划是在与 tempdb 相同的驱动器上创建另一个数据库，将其称为 PseudoTempDB 之类的东西，然后自己处理删除。

任何见解将不胜感激！

我们有一个 SQL Server 2000 生产环境，其中突然（即最近 3 天）某些事情导致 tempdb 数据文件变得非常大（45 gigs，而数据库只有 10 gigs）。昨天，再次发生后，我们缩小了数据库并单独运行了主要的批处理过程，没有任何问题。然而，今天早上数据库恢复到 45 个演出。

有没有一种简单的方法可以找出导致这个数据库变得如此之大的原因？理想情况下，今天可以查看的内容，但如果不可用，则可以设置为明天获取该信息。

顺便说一句：缩小数据库会在几秒钟内收回空间。

在 SQL Server 2000 系统上，我有一个 templog.ldf 文件，该文件似乎无限增长！但是当我检查时，tempdb 中从来没有任何打开的事务（使用 DBCC OPENTRAN），我也没有在 tempdb 中使用显式事务。

但是，我确实在我的存储过程中使用了临时表。谁知道 ASP.NET 数据访问对象在幕后会做什么？该数据库支持一个 ASP.NET 网站。

无论如何，tempdb.mdf 文件——tempdb 数据文件——是相当合理的 700 MB。templog.ldf 文件一天可以增长到 30 GB！如果我没有用完磁盘空间，可能会更多。我没有明确删除存储过程中的#tables，但同样，mdf 文件似乎永远不会变得非常大。

为什么没有未完成的事务时事务日志会增长？事务日志是否会回收空间？此外，带有 NO_LOG 的 DUMP TRAN 不会收缩文件，CHECKPOINT 事件也不会通过 trunc 收缩。在 tempdb 上启用了登录 chkpt。停止 SQL Server 会清除 tempdb（可能 DBCC SHRINKFILE 会，但我没有这样做）。

谢谢你的帮助！

我试图理解tempDB以下是我脑海中浮现的疑问。

1. 数据的生命周期是tempDB多少？假设查询正在执行某些操作Order By并tempDB用于执行该操作。此查询完成后，其他人也执行了一个使用tempDB. 第二个查询会找到第一个查询写入的记录tempDB还是会被删除？
2. Sql Engine内部是否创建了任何可见的表？tempDB我怎么知道由于这个查询而创建了哪个临时表？Sql 引擎是否有任何命名约定来命名这些临时表？

我是新手，tempDB所以请原谅我问了这么愚蠢（如果有的话）的问题:-)

如果有人能给我指出一个可以帮助我了解 tempDB 的好资源，那就太好了。

我有一份报告，它在执行时使用用户名连接到数据库my_report_user。报告可以有许多最终用户。并且在每次执行中都会建立一个到数据库的新连接my_report_user（没有连接池）

我有一个我认为可以只创建一次的结果集（可能是在报告的第一次运行时），其他报告执行可以重用这些东西。基本上每个报表执行都应该检查这个结果集（存储为临时表）是否存在。如果它不存在，则创建该结果集，否则只需重用可用的内容。

我应该使用local临时表 (#) 还是global临时表 (##)？

有没有人尝试过这样的东西，如果是的话，请让我知道我应该关心什么？（几乎同时运行报告等）

编辑：我正在使用 Sql-Server 2005

我在生产服务器中面临一个严重的问题，其中临时数据库呈指数增长。有什么方法可以在不重新启动 SQL 服务的情况下恢复 tempDB 空间？

干杯坎南。

我的 SQL 2005 Server 上有大量查询。这必须每天运行一次，但是当这个查询运行时，temp db 会从 2GB 增长到 48GB。当此查询在单个表上（约 120 列）的 80K 记录上添加/更新时，最佳优化或找到 tempdb 增长的原因是什么？

对于这个 tempdb 不会增长太多的查询，我应该怎么做？

任何建议将不胜感激。

注意：此查询没有任何临时表或表变量或 CTE。只是一堆

我们的应用程序与客户机器上的另一个应用程序一起运行。我们已经在避免 tempdb 中的长时间运行锁方面做出了一些努力，因为这显然会严重影响并发性。但是，另一个应用程序执行以下操作：

开始事务
创建#Table(...);
插入#Table(....) 值(...);
operation_for_totally_six_seconds()。
犯罪;

由于操作需要时间，我们的应用程序会卡住等待其他应用程序获取的锁。

现在，我希望有一种方法可以将我的应用程序与其他应用程序隔离开来，例如告诉 sql server 为我分配另一个 tempdb，但我还没有找到方法。这是可能的还是将我们的数据库安装在另一个 mssql 实例上的解决方案？

问候， Jens Nordenbro