随着数据库使用技术的发展，许多企业都转向了在sql 服务器 上使用数据库。由于数据库技术发展迅速，死锁已经成为非常普遍的问题。死锁指的是多个应用程序之间为了获得某种数据库资源而产生的竞争状态。出现死锁之后，任何一个应用程序都无法运行，因此可能会造成不可估量的损失。
多次出现死锁，给系统管理员带来了巨大的压力。解决死锁的办法一般有以下几种：
* 避免：可以使用冲突锁和间隙锁，它们对不同的资源会有不同的冲突检测和释放机制，从而避免死锁。
* 破坏：当发现死锁时，可以破坏掉其中任意一个参与死锁的进程，以释放占用的资源，以便其他进程能够继续完成工作。
* 解决：在发现死锁之后，可以使用专门的死锁检测模块，解决死锁问题，以便各个资源的争夺可以平衡控制。
另外，还可以采用专有的解决死锁的SQL语句来解决多次出现死锁的问题，代码如下：
— Kill all the blocking session
with cte_Blocks AS
from sys.dm_tran_locks WITH (NOLOCK)
WHERE request_session_id 0x
AND resource_type N’DATABASE’)
FROM cte_Blocks
GROUP BY request_session_id
COUNT(request_session_id) > 0
FROM cte_Blocks
WHERE request_session_id IN
(SELECT request_session_id
FROM cte_Blocks
GROUP BY request_session_id
HAVING COUNT(request_session_id) > 0);
上述代码中，cte_Blocks用来获取SQL服务器中引发死锁的会话，然后使用UNION ALL将其连接在一起，最终就可以杀掉死锁的会话了。另外还可以使用事务，比如Begin Transaction，把死锁的语句包在事务里，出现死锁时就会报错，之后RollBack或者Commit，避免多次出现死锁。总之，使用SQL服务器时，多次出现死锁可能会带来严重的问题，因而，有必要采取相应的措施，如上述SQL语句和事务，来避免和解决多次出现的死锁问题。
香港服务器首选树叶云，2H2G首月10元开通。树叶云（shuyeidc.com）提供简单好用，价格厚道的香港/美国云服务器和独立服务器。IDC+ISP+ICP资质。ARIN和APNIC会员。成熟技术团队15年行业经验。
活锁和死锁是怎么回事？
一、活锁如果事务T1封锁了数据R，事务T2又请求封锁R，于是T2等待。 T3也请求封锁R，当T1释放了R上的封锁之后系统首先批准了T3的请求，T2仍然等待。 然后T4又请求封锁R，当T3释放了R上的封锁之后系统又批准了T4的请求，...，T2有可能永远等待，这就是活锁的情形，如图8.4(a)所示。 避免活锁的简单方法是采用先来先服务的策略。 二、死锁如果事务T1封锁了数据R1，T2封锁了数据R2，然后T1又请求封锁R2，因T2已封锁了R2，于是T1等待T2释放R2上的锁。 接着T2又申请封锁R1，因T1已封锁了R1，T2也只能等待T1释放R1上的锁。 这样就出现了T1在等待T2，而T2又在等待T1的局面，T1和T2两个事务永远不能结束，形成死锁。 1. 死锁的预防在数据库中，产生死锁的原因是两个或多个事务都已封锁了一些数据对象，然后又都请求对已为其他事务封锁的数据对象加锁，从而出现死等待。 防止死锁的发生其实就是要破坏产生死锁的条件。 预防死锁通常有两种方法：① 一次封锁法一次封锁法要求每个事务必须一次将所有要使用的数据全部加锁，否则就不能继续执行。 一次封锁法虽然可以有效地防止死锁的发生，但也存在问题，一次就将以后要用到的全部数据加锁，势必扩大了封锁的范围，从而降低了系统的并发度。 ② 顺序封锁法顺序封锁法是预先对数据对象规定一个封锁顺序，所有事务都按这个顺序实行封锁。 顺序封锁法可以有效地防止死锁，但也同样存在问题。 事务的封锁请求可以随着事务的执行而动态地决定，很难事先确定每一个事务要封锁哪些对象，因此也就很难按规定的顺序去施加封锁。 可见，在操作系统中广为采用的预防死锁的策略并不很适合数据库的特点，因此DBMS在解决死锁的问题上普遍采用的是诊断并解除死锁的方法。 2. 死锁的诊断与解除① 超时法如果一个事务的等待时间超过了规定的时限，就认为发生了死锁。 超时法实现简单，但其不足也很明显。 一是有可能误判死锁，事务因为其他原因使等待时间超过时限，系统会误认为发生了死锁。 二是时限若设置得太长，死锁发生后不能及时发现。 ② 等待图法事务等待图是一个有向图G=(T,U)。 T为结点的集合，每个结点表示正运行的事务；U为边的集合，每条边表示事务等待的情况。 若T1等待T2,则T1、T2之间划一条有向边，从T1指向T2。 事务等待图动态地反映了所有事务的等待情况。 并发控制子系统周期性地（比如每隔1分钟）检测事务等待图，如果发现图中存在回路，则表示系统中出现了死锁。 DBMS的并发控制子系统一旦检测到系统中存在死锁，就要设法解除。 通常采用的方法是选择一个处理死锁代价最小的事务，将其撤消，释放此事务持有的所有的锁，使其它事务得以继续运行下去。 当然，对撤消的事务所执行的数据修改操作必须加以恢复。
deadlocks（死锁）是什么？
在两个或多个任务中，如果每个任务锁定了其他任务试图锁定的资源，此时会造成这些任务永久阻塞，从而出现死锁。 例如：事务 A 获取了行 1 的共享锁。 事务 B 获取了行 2 的共享锁。 现在，事务 A 请求行 2 的排他锁，但在事务 B 完成并释放其对行 2 持有的共享锁之前被阻塞。 现在，事务 B 请求行 1 的排他锁，但在事务 A 完成并释放其对行 1 持有的共享锁之前被阻塞。 事务 A 必须在事务 B 完成之后才能完成，但事务 B 被事务 A 阻塞。 这种情况也称为循环依赖关系：事务 A 依赖于事务 B，而事务 B 又依赖于事务 A，从而形成了一个循环。 除非某个外部进程断开死锁，否则死锁中的两个事务都将无限期等待下去。 Microsoft SQL Server Database Engine 死锁监视器定期检查陷入死锁的任务。 如果监视器检测到循环依赖关系，将选择其中一个任务作为牺牲品，然后终止其事务并提示错误。 这样，其他任务就可以完成其事务。 对于事务以错误终止的应用程序，它还可以重试该事务，但通常要等到与它一起陷入死锁的其他事务完成后执行。 在应用程序中使用特定编码约定可以减少应用程序导致死锁的机会。 有关详细信息，请参阅将死锁减至最少。 死锁经常与正常阻塞混淆。 事务请求被其他事务锁定的资源的锁时，发出请求的事务一直等到该锁被释放。 默认情况下，SQL Server 事务不会超时（除非设置了 LOCK_TIMEOUT）。 因为发出请求的事务未执行任何操作来阻塞拥有锁的事务，所以该事务是被阻塞，而不是陷入了死锁。 最后，拥有锁的事务将完成并释放锁，然后发出请求底事务将获取锁并继续执行。 死锁有时称为抱死。 不只是关系数据库管理系统，任何多线程系统上都会发生死锁，并且对于数据库对象的锁之外的资源也会发生死锁。 例如，多线程操作系统中的一个线程要获取一个或多个资源（例如，内存块）。 如果要获取的资源当前为另一线程所拥有，则第一个线程可能必须等待拥有线程释放目标资源。 这就是说，对于该特定资源，等待线程依赖于拥有线程。 在数据库引擎 实例中，当获取非数据库资源（例如，内存或线程）时，会话会死锁。 在上图中，对于 Part 表锁资源，事务 T1 依赖于事务 T2。 同样，对于 Supplier 表锁资源，事务 T2 依赖于事务 T1。 因为这些依赖关系形成了一个循环，所以在事务 T1 和事务 T2 之间存在死锁。
SQL进程堵塞了，怎么处理？
不知道你用的什么程序，如果没有运行程序执行触发器也死锁，那就是触发器写的有问题如果运行程序才出现死锁情况，那说明程序有编写不正常的地方，你应该查查哪部分对realdata表进行操作了，可能是没有进行数据回滚或者是提交，commit，仔细查查
发表评论