服务代理内部 spid 占用 tempdb

Bob*_*Bob 5 sql-server database-internals service-broker sql-server-2012 tempdb

我们最近在多次接近中断后停用了一个实施得相当糟糕的服务代理设置,但是在我早上检查时,我注意到有 2 个服务代理内部 SPID (<50) 仍然持有约 75% 的 TempDB空间。

现在,我知道这些是服务代理任务,因为 SysProcesses 上的 CMD 列显示“BRKR EVENT HNDLR”和“BRKR TASK”,而最后的等待类型分别是“BROKER_EVENTHANDLER”和“SLEEP_TASK”。两者都将“背景”作为状态,0 开放交易和一个多月前的最后一批时间。

目前服务代理实现已完全禁用(从代码角度),队列已禁用(is_activation_enabled 和 is_receive_enabled = 0),transmission_queue、conversation_endpoints 或实际队列中没有任何内容,但有问题的数据库仍然有 is_broker_enabled = 1(与 TempDB 和 MSDB 一样)。

服务器当前正在运行带有安全修复程序 (11.0.5343.0) 的 SP2,即使在集群故障转移之后,TempDB 的使用似乎仍然存在。我们没有尝试重新启动,因为这是一个生产系统,但我认为故障转移会产生相同的效果。

以前有没有人遇到过这个问题,如果有,你是怎么解决的?

谢谢,

Mar*_*lli 1

正如您在此答案中看到的,查看哪些数据库启用了服务代理(在目标服务器和源服务器上)

您可以使用以下查询来检查哪些数据库启用了代理:

--=====================================================================
-- checking what we have and where we point to
--=====================================================================
SELECT @@SERVERNAME
-- my_target_server

USE [master]
GO
SELECT   [name]
 ,[is_broker_enabled] 
 ,[service_broker_guid]
FROM [sys].[databases] 
WHERE 1=1
  AND is_broker_enabled = 1
ORDER BY  NAME
GO

SELECT name,is_broker_enabled,service_broker_guid,
is_db_chaining_on,  is_trustworthy_on FROM sys.databases
    order by 2 desc, 3 desc,  1
Run Code Online (Sandbox Code Playgroud)

我看到您提到了安全更新和补丁- 应用得很好!

根据环境的不同,我们有时使用数据库链接所有权,有时使用值得信赖的数据库链接所有权,而不是模块签名,这在大多数情况下是最好的方法。

在此输入图像描述

无论如何,如果您不使用代理,请为每个数据库切换所有这些功能,即禁用代理,并将其关闭可信和数据库所有权链。

--我启用其中一些功能并更新代理 ID 的示例之一:

  ALTER DATABASE ORCASTG SET ENABLE_BROKER WITH ROLLBACK IMMEDIATE  
  ALTER DATABASE ORCASTG SET NEW_BROKER with rollback immediate
  ALTER DATABASE ORCASTG SET trustworthy on with rollback immediate
Run Code Online (Sandbox Code Playgroud)

您想要这样的东西(前提是您没有使用任何这些功能):

  USE MASTER 
  ALTER DATABASE [APCore] SET DISABLE_BROKER WITH ROLLBACK  IMMEDIATE  
  ALTER DATABASE [APCore] SET TRUSTWORTHY OFF WITH ROLLBACK IMMEDIATE
  ALTER DATABASE [APCore] SET DB_CHAINING OFF WITH ROLLBACK IMMEDIATE
Run Code Online (Sandbox Code Playgroud)

并继续监视tempdb 使用情况,我认为您既不需要重新启动服务,也不需要进行故障转移。

无论如何,如果您位于alwaysOn - 可用性组上,您可能需要先从可用性组中删除数据库,然后才能禁用代理。


归档时间:

查看次数:

454 次

最近记录:

5 年 前