【问题标题】:Sql Server 2000 - tempdb growing very largeSql Server 2000 - tempdb 变得非常大
【发布时间】:2009-07-13 14:51:20
【问题描述】:

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

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

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

【问题讨论】:

  • 听起来像是一个 Server Vault 问题......但你可能想看看 Sql Profiler。

标签: sql-server-2000 tempdb


【解决方案1】:

同意 Jimmy 的观点,您需要使用 SQL Profiler 来查找创建如此密集的临时对象。这可能是使用某些报告或类似内容的临时表。

【讨论】:

  • 我设置了一些 Profiler 跟踪来运行整夜跟踪可能的事件:跟踪运行时间超过 10 秒的任何事情,任何产生超过 1M 数据读取的事情,任何产生超过 1M 的事情写入次数(这将是三个单独的跟踪)。很难说,很大程度上取决于你的环境和系统;追踪这些东西可能需要很多时间(因为你只能在一夜之间运行并在第二天检查)。由于它是 tempdb,它可能是一个单一的大动作,而不是一堆小家伙(除非你已经声明了交易)。
【解决方案2】:

我要感谢大家的回答,因为他们肯定导致了问题的原因。

我们打开了 SQL 分析器,果然出现了大批量负载。由于我们正在开展一个项目以将“有问题的”工作转移到 mysql 中,我们现在可能只是观察一下。

【讨论】:

    【解决方案3】:

    您是否正在运行重建索引的作业?它可能使用 SORT_IN_TEMPDB

    或任何其他进行排序的大型查询可能会扩展 tempdb

    【讨论】:

      【解决方案4】:

      这可能与 TempDB 设置的恢复模式有关。它可以设置为 FULL 而不是 BULK-LOGGED。完全恢复会增加事务日志的大小,直到执行备份。

      查看数据文件大小与事务日志大小。

      【讨论】:

        【解决方案5】:

        我不是 DBA,但有一些想法:

        • 是否有可能有温度 正在创建但未删除的表? ##tempTable?
        • 有没有可能 有一个很大的临时表 创建(并删除)但空间 不回收吗?
        • 你在做什么 排序的批量加载系统 可以使用临时表吗? (我不是 确定是否可以)但你能打开 为 tempdb 自动收缩?

        【讨论】:

          猜你喜欢
          • 1970-01-01
          • 1970-01-01
          • 1970-01-01
          • 1970-01-01
          • 1970-01-01
          • 2014-07-23
          • 2012-08-31
          • 1970-01-01
          • 1970-01-01
          相关资源
          最近更新 更多