我们在生产系统中有一个表（由于遗留原因）运行SQL 2005（9.0.5266）并包含一个TEXT列（以及其他一些不同数据类型的列）。
突然（从一周前开始），我们注意到这一张桌子的大小每天线性增加10-15GB（而之前它一直保持恒定大小）。该表是消息传递系统的队列，因此其中的数据每隔几秒就会完全刷新一次。在任何时候都可能有0到1000行左右，但随着消息的插入和发送，它会迅速波动（此时它们被删除）。
我们在增长开始的那天找不到任何改变的东西 - 所以在这个阶段没有明显的潜在原因。
一个“显而易见”的罪魁祸首是TEXT专栏，因此我们检查现在是否存储了任何大量值，但是（使用DATALENGTH）我们发现大约32k左右没有单行。我们运行CHECKDB，更新空间使用，重建所有索引等 - 没有减小大小（并且CHECKDB没有显示错误）。
我们查询了sys.allocation_units，大小增加肯定是LOB_DATA（显示total_pages和used_pages以恒定速率一起增加）。
为了减少昨晚的数据库大小，我们简单地创建了一个新表与所讨论的一个表（幸运的是通过应用程序的视图引用），删除了旧表，并重命名了新表。我们昨晚离开了，因为我们已经缓解了太空问题而感到安慰，而且我们对这个狡猾的桌子进行了备份，以便今天进一步调查。 但是，今天早上表格大小已经达到14GB（并且还在增长），而表格中通常只有大约500行，而MAX（DATALENGTH（text_column））只显示大约35k。
关于什么可能导致这种“失控”增长的任何想法，或者我们可以尝试或查询以获取有关使用该空间的确切内容的更多信息的任何其他内容？
干杯， 戴夫
答案 0 :(得分：0)
今天早上我用这个“问题队列表”重新启动了实例上的SQL服务。这似乎解决了这个问题。在重新启动后，我立即监视LOB_DATA页面使用计数，并立即开始下降。它被清理得非常缓慢，所以可能需要大约一两个小时才能收回60 + GB的空间（我确保一切顺利后我上床睡觉了）。
目前该表已恢复正常，直至使用中的分配（徘徊在<100页左右），并且没有显示任何重新增长的迹象。
鉴于我们以相同的方式（即作为队列）使用此表至少10年，并且它比我们过去一周或两周的时间更加繁忙，我会'如果它是上面Remus描述的问题，我会感到惊讶（虽然我明白这是怎么发生的;我猜这个特定的队列不是很忙，不足以淹没幽灵清理过程？）。很奇怪......
再次感谢帮助人员！