SQL Server 2012笔记分享-20：了解死锁和阻塞的概念

=================================================================
阻塞

阻塞是死锁产生的必要条件。
当进程没有所需的资源时，比如说等待IO，等待打印 机，这时是阻塞状态。而当进程获得了这些资源时，就可以变为就绪状态，在就绪状态的进程再获得CPU时，就变为执行状态。而执行的过程中，CPU被剥夺了 就继续变为就绪状态，或是当需要其它资源时，就会继续变为阻塞状态。以此往复。
死锁
死锁的本质是一种僵持状态，是多个主体对于资源的争用而导致的。
在多并发的环境中，死锁是不可避免的，只能尽量的通过合理的数据库设计，良好的索引，适当的查询语句以及隔离等级来尽量的减少。因此， 检测死 锁的目的是知道哪里可能会产生死锁，通过对检测到的死锁进行分析后，尽量的优化查询/索引/隔离等级来降低死锁发生的可能性。
查看死锁有两种方式，一种是通过服务端的Trace来做，另一种是通过SQL Profiler，首先让我们来看通过Trace来抓死锁。
参考
SQL Server死锁详解 http://www.uol123.com/2012/09/25/sql-server死锁详解.html http://www.cnblogs.com/CareySon/archive/2012/03/22/2411292.html#!comments
=======================================================================
死锁deadlock
当一个进程锁定了另一个进程需要的页或者表的时候，而第二个进程又锁定了第一个进程需要的一页，这个时候就会发生死锁。死锁也叫抱死。 SQL Server自动探测和解决死锁。如果找到一个死锁，服务器将终止完成了抱死的用户进程。
阻塞block
当来自应用程序的第一个连接控制锁而第二个连接需要相冲突的锁类型时，将发生阻塞。其结果是强制第二个连接等待，而在第一个连接上阻塞。不管是来自同一应用程序还是另外一台客户机上单独的应用程序，一个连接都可以阻塞另一个连接。说明 一些需要锁保护的操作可能不明显，例如系统目录表和索引上的锁。大多数阻塞问题的发生是因为一个进程控制锁的时间过长，导致阻塞的进程链都在其它进程上等待锁。
参考
死锁和阻塞的理解(ZT) http://www.cnblogs.com/dafanchen/archive/2012/08/17/2643904.html =======================================================================
当一个用户会话（会话1）已经锁定了一个资源，而另一个会话（会话2）想要修改该资源，并且会话2也锁定了会话1想要修改的资源时，就会出现“死锁”(deadlocking)。在另一方释放资源前，会话1和会话2都不可能继续。所以，SQL Server会选择死锁中的一个会话作为“死锁牺牲品”。
注意：死锁牺牲品的会话会被杀死，事务会被回滚。
注意：死锁与正常的阻塞是两个经常被混淆的概念。
参考： http://blog.csdn.net/downmoon/article/details/6211663