建议处理死锁

Question

有6个程序在内部调用以从事务表中获取数据，并对检索到的数据进行聚合，形成XML，然后每小时发送一次电子邮件。

在此过程中，许多登录完成和日志也以HTML格式（在同一封电子邮件中）作为电子邮件发送。有一个程序发生死锁，电子邮件的一部分总是丢失或我们发生死锁（LOGS）。所以为了处理我试图在该特定过程中使用READ_COMMITTED_SNAPSHOT。任何人都可以建议如果这对他们有用，或者哪个是处理这种僵局的最佳方法。

我可以通过检查输出是否为空来在内部重试该特定过程。

我不能让其他进程失败，因为这是一个事务。但是我需要HTML来显示所有信息而不会遗漏任何内容。

编辑：这很少发生。但现在频率每天都在增加。我无法理解，因为该过程只是试图从事务表中读取并进行一些计算并将其格式化为XML而另一个事务是写入事务表。那么WRITE如何影响READ

Answer 1

您需要修复死锁才能解决此问题。

当一个进程拥有另一个进程所需的资源以进行反复时，会发生死锁。当您有两个进程在不同的订单中获取相同的资源集时，您将陷入僵局。例如，如果进程P1按以下顺序获取资源：

1. 资源A
2. 资源B

竞争过程P2需要不同顺序的相同资源：

1. 资源B

2. 资源A

   • P1启动并获取对资源A的独占访问权。
   • P2启动并获取对资源B的独占访问权。

为了使每个都继续，P1需要访问资源B，P2需要访问资源A.

他们都无法获得所需的资源，从而导致死锁。

这与阻止不同，其中一个进程只是在等待另一个进程释放所需的资源。如果有足够的时间，阻止将得到解决。在死锁中，阻塞无法解决。

SQL引擎可以（并且确实）检测死锁情况。它通过选择一个进程或另一个进程作为死锁受害者并回滚来解决它。

通过识别问题并解决问题来修复死锁，而不是简单地重试并希望它通过。 SQL Trace可以帮助您识别问题。您可能需要DBA来帮助您。

Answer 2

更简单（危险性更小）的方法是更改​​有问题的六个程序，以便它们进行脏读（即WITH（NOLOCK））。这应该在死锁中起作用，尽管你可能会得到垃圾数据。