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 回答