我昨天修改了一个维护计划，今天早上（通过使用来自 sysjobs 的最后修改日期）发现与维护计划相关的所有作业都被禁用。
我无法弄清楚为什么会这样。SQL 作业所有者是sa，我只是用维护计划更改了维护清理任务并保存了作业。
昨天我们遇到了一个关键问题，其中一个 1 秒的存储过程开始需要几分钟才能执行。我目前还不知道业务逻辑，但是想了解使用sp_GetAppLock.
所以场景是：
调用存储过程usp_abc，无参数
存储过程中的代码如下所示：
BEGIN
BEGIN TRANSACTION
sp_getapplock @Resource = usp_abc, @LockMode = 'Exclusive'
with cte_1
( SELECT TOP 1 ID FROM tbl1 WHERE Status = 'OK')
UPDATE tbl1
SET Status = 'Complete'
WHERE ID = (SELECT ID FROM cte_1)
COMMIT TRAN
END
这个存储过程是从同一个应用程序调用的，但是在来自两个不同应用程序服务器的负载平衡器上。存储过程不断执行，昨天因为积压，我们遇到了更多问题（每秒多次）。
我昨天在查询 sp_who2 时看到的是存储过程的执行被较早的执行阻止了。大约有 5 个 SPID 在做同样的事情。我追溯了第一个 SPID 以查看资源等待。它在SOS_SCHEDULER_YIELD和 APPLICATION:5.0 " usp_abc"之间波动- 基本上是它本身。
看起来它自己陷入了一个令人讨厌的循环，但有时执行确实完成了。在没有锁定的情况下自行运行更新时，它按预期运行亚秒。
一旦负载平衡器关闭并且请求来自单一来源，问题就在查询中消失了。
这不是我们的代码，但是我们想就如何阻止这种情况再次发生提出建议。据我所知，开发人员出于并发原因并可能避免死锁而将其设置到位。
然而，根据代码判断，在这种情况下，本机 sql 读取提交应该就足够了，因为它应该锁定正在更新的数据，这意味着不可能两次更新同一条记录。我认为这个查询不会出现死锁问题。
你怎么看？
我们有一个服务器，在 2 个 NUMA 上有 8 个 CPU，并启用了超线程。当前 Maxdop 设置为 8，但实际上应该按照本文的 Maxdop 部分设置为 4：
https://support.microsoft.com/en-us/kb/322385
所以我们需要把它改成4。
但是我的问题是将 maxdop 设置为 8 有什么影响？那么并行跨越两个 NUMAS 吗？我问的原因是我们刚刚遇到了一个奇怪的问题，查询返回非常慢，而 PLE 迅速下降。
即使没有针对 SQL 运行，PLE 也没有改进。CXPACKET 等待类型上升。然后突然 CXPACKET 等待类型完全下降，PLE 开始上升，现在已经恢复正常。
在这段时间里，对数据库执行了小查询，但并不是一个查询完成导致 CXPACKET 等待类型下降而 PLE 再次上升的情况 - 我们不知道是什么原因造成的。
一个可能的解释是 MAXDOP 设置不正确。
谁能向我解释跨 NUMA 节点并行执行的影响，是否与使用外部内存时耗尽工作线程和更慢的访问时间相同？
谢谢