TempDB 内部空间使用量从 Service Broker 缓慢增长

Question

正在SQL Server 2012 (11.0.6540.0)与另一台服务器一起在 AO 高可用性组中运行。

tempDB 使用量通常约为 819MB（从 2 周前开始平均超过一周），但由于我们进行了故障转移和补丁周期，tempDB 开始逐渐增长（此时未进行 DDL 更改）。我们刚刚完成了一个测试故障转移，并将 tempDB 从两台机器都可以访问的联合 SAN 驱动器上移开，（我们不希望一个硬件可以同时关闭我们的主要和次要副本）。

最近的故障转移和实例重新启动（移动 tempDB）看到 tempDB 使用量跃升至 6348MB，并且其缓慢增长。

增长全部在内部对象上，可以使用以下方法查看：

SELECT   top 5 session_id, request_id, 
         SUM(internal_objects_alloc_page_count) AS request_internal_objects_alloc_page_count
FROM     sys.dm_db_task_space_usage 
GROUP BY session_id, request_id
ORDER BY request_internal_objects_alloc_page_count DESC

看看它，它都是从 spid 35 和 32 运行的，它们都与服务代理相关。

我环顾四周，有人谈论这是由于进行WITH CLEANUP了最后的对话，但清理这个词只出现在评论中，所以我相信这不是问题。

当实例恢复并接管主节点时，服务代理不工作，所以我需要将所有队列循环到禁用然后启用状态（我们在一年前必须这样做，但没有请参阅此问题）。

您可以在此处查看 tempDB 上的使用情况，因为它目前在过去 4 天中保持不变。今天早上的下降是实例重启和故障转移。

有谁知道我缺少什么来控制它。

Answer 1

太长了；检查对话是否完全开放。

在我们的系统中，我们重复使用对话，并有一个专门用于保存这些可用对话的表，但是开发团队在我很久以前下班时在我不知情的情况下设置了一个新的服务代理，没有设置这些对话点，也没有不要对警报设置任何阈值。

当新系统打开时，对话正在打开，但没有正确关闭，并且由于池中没有任何对话，因此它只是创建一个新对话（我们为一个服务代理达到了 710 万个对话）

我的修复步骤是创建并记录该服务代理所需的 20 个对话处理程序，并将它们记录到我们的表中。这阻止了 tempDB 的增长，从而阻止了 DB 下降的风险。

然后是关闭所有未使用的对话的漫长过程

select 
    se.[conversation_handle] 
from 
    sys.conversation_endpoints se with (nolock) 
    left outer join [queue].[maintained_Conversations] qh with (nolock) on qh.[conversation_handle] = se.[conversation_handle]
where 
    qh.service_name is not null 
    and se.far_service = @service

通过这些值给出所有 ID 游标的列表，并简单地END CONVERSATION @id;在每个值上运行。

该过程完成后，临时数据库空间将放松（请注意，当您关闭它们时，它不会执行此操作，当您不再创建/结束它们时，它似乎会大块地执行此操作（我不能保证这是它是如何工作的，正是我在停止中间进程和 tempDB 恢复一些空间后观察到的情况）