锁和并发性----锁

SQL Server通过锁定一块数据来阻止访问它，有各种各样的锁类型（模式）。几乎各种数据访问都需要一种锁，即使是读取，这意味着锁实际上是阻塞其他类型的锁。

监视锁

有两个主要的DMV用于监视锁：sys.dm_tran_locks和sys.dm_os_wait_stats。前者罗列所有当前使用的所，包括识别锁资源的信息等；后者罗列捕获各种锁类型时进程等待的相关信息。下图显示了2个DMV的部分信息

锁资源

锁资源是指DATABASE、FILE、OBJECT、PAGE、KEY、EXTENT、RID、APPLICATION、METADATA、HOBT 或 ALLOCATION_UNIT等。一个对象的锁定可以覆盖多个HoBT锁，HoBT锁反过来能够覆盖成千上万个页，页知道多少行。

锁模式

共享（S）：当一个任务对一行数据发出读请求时，SQL Server就会默认请求一个共享锁。共享锁与大部分其他锁兼容，因为它仅被允许读取数据页上的行。

更新（U）：用于数据修改请求期间搜索数据的时候。希望锁定带有更新或排他锁的资源的其他请求都被迫要等待。然而，为了达到数据修改的目的，更新锁必须转换成排他锁。

排他（X）：用于INSERT,UPDATE和DELETE修改数据。排他锁与任何其他锁都不相兼容。

架构：在执行依赖于表架构的操作时使用。 架构锁包含两种类型，即架构修改 (Sch-M) 和架构稳定性 (Sch-S)。

意向：用于建立锁的层次结构，针对层次结构中某些低层资源请求或获取。 意向锁包含三种类型：意向共享 (IS)、意向更新 (IU) 和意向排他 (IX)。

转换：SIX,SIU,UIX。当事务中一个语句拥有一个粗粒度（表）的锁，但现在需要修改拥有细粒度（行）的资源组件时，就会出现SIX,SIU,UIX。

大容量更新（BU）：在向表进行大容量数据复制且指定了 TABLOCK 提示或使用 sp_tableoption 设置了 table lock on bulk load 表选项时使用。BU锁允许多个线程将数据并发地大容量加载到同一表，同时防止其他不进行大容量加载数据的进程访问该表。场景如下SQL：

BULK INSERT dbo.TestFactInternetSales
FROM 'C:\factinternetsales.txt'
WITH (TABLOCK
,FORMATFILE = 'C:\formatFIS.txt'
);

键范围：当使用可序列化事务隔离级别时保护查询读取的行的范围。 确保再次运行查询时其他事务无法插入符合可序列化事务的查询的行。在使用可序列化事务隔离级别时，对于 Transact-SQL 语句读取的记录集，键范围锁可以隐式保护该记录集中包含的行范围。 键范围锁可防止幻读。 通过保护行之间键的范围，它还防止对事务访问的记录集进行幻像插入或删除。

兼容性矩阵

简单的兼容性矩阵如下图：

完整的兼容性矩阵如下图所示：

锁升级
一个T-SQL语句中的一个特定表的行或页有超过5000个锁时，就会触发锁升级。在这个过程中，更高层的意向锁会转换为全锁----假如升级为全锁成为可能并且没有被其他锁阻止----那么更多细粒度的锁会被释放，腾出需要管理的资源。如果由于并发事务所持有的锁冲突而导致锁升级尝试失败，则数据库引擎将对事务获取的其他 1,250 个锁重试锁升级。你可以使用跟踪标志 1211 和 1224 来禁用锁升级。更多信息可以参考http://msdn.microsoft.com/zh-cn/library/ms184286(v=sql.105).aspx。

死锁

数据库引擎侦测到死锁时，会终止一个线程，解析死锁。终止的线程获取一个1205错误，它建议如何解决它：
Error 1205 : Transaction (Process ID) was deadlocked on resources with another process and has been chosen as the deadlock victim. Rerun the transaction.

的确，重跑事务常常是最好的做法。一个事务锁定一个资源，然后试图获取另一个资源上的锁但被另一个事务阻塞。直到第二个事务完成并释放它的锁，第一个事务才能完成。然而，如果第二个事务做什么要等待第一个事务，它们将永久等待。幸运的是，数据库引擎会侦测到，并终止其中一个进程。诊断问题可以使用追踪事件，如Lock:Deadlock和死锁图表事件。更多关于死锁的信息可以参考http://msdn.microsoft.com/zh-cn/library/ms177433(v=sql.105).aspx。