相关疑难解决方法(0)

我想知道如何识别实际填充 TEMPDB 数据库事务日志的确切查询或存储过程。

我在我们的生产 sql 服务器上遇到了一个问题，其中临时表对象需要很长时间才能删除（当使用小型同步删除时很明显）。我无法在其他 sql 服务器上重现这一点（同样指定使用相同数量的主轴来提供 tempdb 数据文件（拆分为相同数量的文件（每个物理核心 1 个））。在 SQL 2005 Enterprise (SP2 - 3042) 上。

更新：还有一个因素——看起来最有可能。该服务器上有 >500 个数据库。另一个大于 800 的服务器也运行这些 drop 很慢。那是我唯一拥有很多数据库的其他服务器。

第二次更新：重启有问题的服务器将允许立即执行 create 和 drop 语句。在接下来的几个小时内（在应用程序运行时），测试的性能会下降，直到达到（看起来是）平台期。我有一项在后台运行的工作，每 30 分钟测试一次。我会看看几天后的结果，看看执行时间是否相同。我认为他们会。

第三次更新：虽然没有一个正在执行的语句显示闩锁等待 CPU 资源，但使用 sp_whoisactive 我看到在 delta_interval = 30（秒）运行期间，运行查询 CPU_delta 报告大约 30,000（毫秒？），当我在执行期间观察 perf 时在执行期间似乎有一个核心的 CPU 峰值。这些在 16 个 cpu 盒上，因此当其他流量发生时通过 perfmon 看到可能有点困难，但它似乎在执行 drop 语句期间增加了 cpu 的价值。

在我测试过的大多数服务器上，创建和销毁 20 个具有唯一名称（一列，无行）的小型临时表的时间不到 20 毫秒。在一台服务器上需要> 5 秒。绝大多数 (>95%) 的时间都花在 drop 语句上。

在执行期间，没有显式等待，也没有报告阻塞，并且 perfmon 不显示 I/O 子系统上的任何数据或日志文件负载。

我查看了高峰和低使用时间，当大量表标记为销毁和低时。操作需要 5 秒左右来处理 20 个 drop …