0

我编写了一个从 Management Studio 执行时需要15 分钟的存储过程。但是，当它从 Service Broker 激活时，4 小时后它甚至还没有完成一半的工作。

从 Service Broker 运行 SP 时是否存在已知的性能问题？（也许 Service Broker 在事务中运行 SP 而 Management Studio 没有？）

我正在使用 SQL Server 2005。

更新：

看来问题是从另一个存储过程执行存储过程。更具体地说，我有一个接收操作（导出或删除）的存储过程。然后这个SP根据操作调用各自的SP（一个有ETL过程，另一个删除数据）。在这些 SP 上强制重新编译似乎已经解决了这个问题。我想知道 SQL Server 是否应该为每个子 SP 制定一个行动计划，独立于调用它们的 SP。在这种情况下，不需要重新编译。

4

1 回答 1

1

我不了解 Service Broker，但对于一般存储过程故障排除，请查看此问题中给出的建议。他们帮助我解决了存储过程的一些问题。

您可以查看存储过程在 WhoIsActive 例程中的作用，您可以获取查询计划并研究在 Management Studio 中执行时与查询计划是否有任何差异，您可以尝试使用OPTIMIZE FOR提示来消除参数嗅探...

（参数嗅探是在提供其他参数时查询计划的生成方式不同。Service Broker 是否将与您在 Management Studio 中传递的参数相同的参数传递给您的 SP？）

祝您好运，如果您不成功，请在此处发布您的发现。

于 2010-11-11T23:24:02.343 回答