sql-server - 大约一天后，Service Broker 消息开始挂起

Question

我有一个使用 Service Broker 的应用程序是 SQL 2008。大约每天一次，数据库的性能开始受到明显的影响，我确定这是由 Service Broker 造成的。如果我使用以下命令硬重置所有代理连接:

ALTER DATABASE [RegencyEnterprise] SET OFFLINE WITH ROLLBACK IMMEDIATE
ALTER DATABASE [RegencyEnterprise] SET ONLINE

然后性能恢复正常，直到第二天左右。我还注意到，当性能较差时，运行以下查询会返回大量(当前约为 1000 个)陷入 STARTED_OUTBOUND 状态的对话:

SELECT * FROM sys.conversation_endpoints

此外，以下查询不会返回其中的任何条目:

SELECT * FROM sys.dm_qn_subscriptions
SELECT * FROM sys.transmission_queue

当此查询返回大量项目时，性能似乎还不错。唯一出现问题的情况是 STARTED_OUTBOUND 连接停留在此状态时。

我对 SQL Server 2008 实例上的 Service Broker 所做的唯一配置是运行以下命令:

ALTER DATABASE RegencyEnterprise SET ENABLE_BROKER

通过挖掘 SQL 错误日志，我也发现了该条目超过 1000 次:

07/11/2013 01:00:02,spid27s,Unknown,The query notification dialog on conversation handle '{6DFE46F5-25E9-E211-8DC8-00221994D6E9}.' closed due to the following error: '<?xml version="1.0"?><Error xmlns="http://schemas.microsoft.com/SQL/ServiceBroker/Error"><Code>-8490</Code><Description>Cannot find the remote service &apos;SqlQueryNotificationService-cb4e7a77-58f3-4f93-95c1-261954d3385a&apos; because it does not exist.</Description></Error>'.

我还在整个日志中看到这个错误十几次左右，尽管我相信我可以通过在数据库中创建主 key 来解决这个问题:

06/26/2013 14:25:01,spid116,Unknown,Service Broker needs to access the master key in the database '<Database name>'. Error code:26. The master key has to exist and the service master key encryption is required.

我认为这些错误的数量可能与停留在队列中的对话数量有关。以下是我用来订阅查询通知的 C# 代码:

private void EstablishSqlConnection(
    String storedProcedureName,
    IEnumerable<SqlParameter> parameters,
    Action sqlQueryOperation,
    String serviceCallName,
    Int32 timeout,
    params MultipleResult[] results)
{
    SqlConnection storeConnection = (SqlConnection) ((EntityConnection) ObjectContext.Connection).StoreConnection;
    try
    {
        using (SqlCommand command = storeConnection.CreateCommand())
        {
            command.Connection = storeConnection;
            storeConnection.Open();

            SqlParameter[] sqlParameters = parameters.ToArray();
            command.CommandText = storedProcedureName;
            command.CommandType = CommandType.StoredProcedure;
            command.Parameters.AddRange(sqlParameters);

            if (sqlQueryOperation != null)
            {
                // Register a sql dependency with the SQL query.
                SqlDependency sqlDependency = new SqlDependency(command, null, timeout);
                sqlDependency.OnChange += OnSqlDependencyNotification;
            }

            using (DbDataReader reader = command.ExecuteReader())
            {
                results.ForEach(result => result.MapResults(this, reader));
            }
        }
    }
    finally
    {
        storeConnection.Close();
    }
}

以下是我处理通知的方式:

    public static void OnSqlDependencyNotification(object sender, SqlNotificationEventArgs e)
    {
        if (e.Info == SqlNotificationInfo.Invalid)
        {
            // If we failed to register the SqlDependency, log an error
            <Error is loged here...>

            // If we get here, we are not in a valid state to requeue the sqldependency. However,
            // we are on an async thread and should NOT throw an exception. Instead we just return
            // here, as we have already logged the error to the database. 
            return;
        }

        // If we are able to find and remove the listener, invoke the query operation to re-run the query.
        <Handle notification here...>
    }

有谁知道什么会导致代理的连接进入这种状态？或者我可以使用哪些工具来尝试找出导致此问题的原因？我目前只有一个正在注册其通知的 Web 服务器，因此我的场景并不太复杂。

更新:

好的，所以我从 this post 确定错误“找不到远程服务...因为它不存在”是由于 SqlDependency 未正确清理自身造成的。服务结束后，代理仍在尝试向我的应用程序发送通知。所以现在，听起来我只需要找到一种方法来清除当我的应用程序在调用 SqlDependency.Start() 之前启动时未正确清理的任何内容，但除了我原来的方法之外，我还没有找到一种方法来做到这一点以上，这会使数据库脱机，这是 Not Acceptable 。有谁知道如何清理这个吗？

Answer 1

我找到了解决此问题的可接受方法。首先，我将代码从 SqlDependency 迁移出来，现在改用 SqlNotificationRequest。这样做可以防止代理队列和服务在意外时间被创建/销毁。

然而，即使这样，当我的应用程序退出时，仍然有一些对话没有被标记为关闭，因为设置通知的原始端点不再存在。因此，每次我的服务器重新初始化我的代码时，我都会清除现有的对话。

此调整将我每天拥有的连接数量从超过 1000 个且必须手动终止连接减少到始终最多保持约 20 个。我强烈建议使用 SqlNotificationRequest 而不是 SqlDependency。