从Service Broker激活时的存储过程缓慢

我已经编写了一个存储过程，它在从Management Studio执行时需要15分钟。然而，当它从Service Broker启动时，在4小时之后，它甚至没有完成其一半的工作。从Service Broker激活时的存储过程缓慢

从Service Broker运行SP时是否存在已知的性能问题？（也许Service Broker的运行事务中的SP和管理工作室不？）

我使用的是SQL Server 2005中

更新：

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

来源

2010-11-11 noup

请提供更多信息（例如程序的作用等） – 2010-11-15 20:05:28

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

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

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

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

来源

2010-11-11 23:24:02 thomaspaulb

无所事事，程序也从Service Broker开始快速运行。我不知道（自动）更改是如何引起的。 Management Studio中的参数相同。无法让WhoIsActive返回任何内容，但Who和Who2会返回结果。 – noup 2010-11-12 15:34:09

是的，我的SP也放慢了速度，然后快速“无中生有”。然后在一个月内，再次出现同样缓慢的行为。这很烦人，而且我还没有把所有原因固定下来，但至少现在我现在可以开始寻找 - 而且你也是。我想知道你将来遇到这样的问题时的经历，我们可以互相学习。在这里放下一行。 – thomaspaulb 2010-11-23 10:46:26

再次发生，这次用手动运行需要9秒的查询。一些说明：我没有使用交易;该进程在sp_who2中具有“后台”状态;正如我的更新中提到的那样，我有一个SP1多次调用SP2（每次导出都需要完成） - 这次第三次调用SP2时出现缓慢。 – noup 2010-11-23 18:20:31

从Service Broker激活时的存储过程缓慢

回答

相关问题