1

I have a stored proc that calls a series of stored procs as part of an account update. Unfortunately I have a 10-minute limit (unrelated to SQL-Server, external timeout) and sometimes it exceeds the timeout. (Under the right conditions it could go an hour.)

I've tried various solutions. The code is about as optimized as it's going to get. One solution would simply be to have an initial stored proc call the "real" stored proc; since the timeout only knows of the initial proc, the real proc can continue unimpeded. The problem is that SQL-Server nests the procs... proc A won't finish until the procs it called (procs B, C and D) are finished.

SQL-Server's internal messaging would work, but our DB isn't compatible. (Out of my control.) I thought about having the initial proc set up a one-time job (to run a minute later) and let the job scheduler run it, but our DBAs probably won't be happy if I'm adding and deleting jobs all the time.

Is there any way for a stored proc to EXEC another stored proc, then immediately quit while the called proc continues to run?

4

1 回答 1

2

我过去用两种方式解决了这个问题。一种选择是设置 Service Broker 以将消息发送到队列中，并在 Service Broker 的另一端执行第二个存储过程。另一种选择是插入队列表并定期运行 SQL 代理作业（例如，每 5-10 分钟），执行第二个存储过程。无论哪种方式，您的第一个 sproc 都会执行，成功完成事务，然后第二个过程（使用它自己的事务）将拿起排队的工作并完成它。

对于 Service Broker，此页面将有所帮助： http: //msdn.microsoft.com/en-us/library/ms345108 (v=sql.90).aspx

无论哪种方式，您都在某个时候涉及 DBA，但是如果您有一个针对队列表执行存储过程的常规作业，您不需要一直添加和删除作业，只需在队列表（即，来自 DBA 的一次性设置请求与来自 DBA 的持续请求，通过添加/删除作业，如 OP 所述）。

于 2013-05-07T23:20:13.623 回答