sql-server - sp_getapplock 是否会导致 SQL Server 性能问题？

Question

我有一个不能同时执行的存储过程。多个进程调用此存储过程，但进程顺序访问存储过程至关重要。

存储过程基本上是在一张表中扫描满足各种条件的主键，将该记录标记为调用进程正在使用，然后将主键传递回调用进程。

可能存在一到十个调用进程实例，具体取决于存在的工作量。

我决定在存储过程中使用 sp_GetAppLock 来防止并发。我捕获了一个排他事务锁，将 @Resource 设置为一个仅在此存储过程中使用的字符串。唯一被这个锁阻塞的是这个存储过程的执行。

存储过程中的调用如下所示:

     sp_getapplock @Resource='My Unique String Here' 
         ,@LockMode='Exclusive'  -- Type of lock
         ,@LockOwner='Transaction' -- Transaction or Session
         ,@LockTimeout = 5000

它运行顺畅。如果我的进程有十几个实例在运行，那么任何一个时间点只有一个执行存储过程，而另外11个则乖乖排队等待轮到他们。

唯一的问题是我们的 DBA。他是一个非常优秀的 DBA，他会持续监控数据库的阻塞情况，并在超过某个阈值时收到警报。我对 sp_getapplock 的使用会触发很多警报。我的 DBA 声称阻塞本身就是一个性能问题。

他的说法准确吗？我的感觉是这是“好的”阻塞，因为唯一被阻塞的是存储过程的执行，而我希望将其阻塞。但我的 DBA 说，强制 SQL Server 强制执行此阻塞会严重消耗资源。

我可以告诉他像我们过去常说的那样“放下爆裂的 pipe ”吗？或者我应该重新编写我的应用程序以避免需要 sp_getapplock？

我在 sp_getapplock 上读到的那篇卖给我的文章在这里:sp_getapplock

Answer 1

不幸的是，我认为您的 DBA 有一个观点，阻塞确实会消耗资源，并且这种类型的阻塞会给服务器带来额外的负载。

让我解释一下:

1. Proc 被调用，SQL Server 将线程池中的工作线程分配给它并开始执行。

2. 调用 2,3,4,... 再次进入，SQL Server 再次为这些调用分配工作线程，线程开始执行，但由于您获得了独占锁，所有线程都被挂起并坐下在 "Waiting List" 中以使资源可用。

3. 由于您的进程，在任何 SQL Server 上数量非常有限的工作线程都被保留。

4. 现在，由于开发人员决定做某事，SQL Server 正在累积等待。

作为一名 DBA，我们希望您来 SQL Server 获得所需的东西并尽快离开。如果您故意留在那里并持有资源并使 SQL Server 承受压力，它会激怒 DBA。

我认为您需要重新考虑您的应用程序设计并提出替代解决方案。

可能是 SQL Server 中的“进程表”，在进程启动时使用某个值对其进行更新，并且每次调用都首先检查进程表，然后再触发该进程的下一次调用。所以等待的东西发生在应用层，只有当资源可用时才去数据库。