阻塞与死锁

1,锁发生在事务中。事务的4个属性是:原子性,一致性,隔离性,持久性。(ACID)
1)原子性:对于数据的修改,要么全部执行,要么全部不执行,不存在一部分修改而另一部分未变的情况,即使执行一半发生断电的情况,下次启动时也会读取日志将上次未完的操作执行下去(故对于事务,日志优先写入)。
2)隔离性:对于数据的修改,同一时间只能由一个事务处理
3)一致性:事务完成时,必须使所有数据都保持一致状态。
4)持久性:事务完成之后,它对于系统的影响是永久性的。

2,隔离级别:mssql通过对共享锁申请和释放机制的不同处理,实现不同事务隔离级别。
1)隔离等级:
隔离级别 是否申请共享锁 何时释放 有无范围锁
未提交读 否 无 无
已提交读 是 当前语句执行完 无
可重复读 是 事务提交时 无
可序列化 是 事务提交时 有

在事务里面:
未提交读就是你读的同时我可以读写
已提交读取就是你读时我也可以读,但你读完后我才可以写,读操作共享锁时间一直到读取结束。
可重复读:事务提交时我才能写,读操作共享锁时间一直到事务结束。
注:未提交读:允许脏读,因此一个事务可能看见其他事务所做的尚未提交的更改。
已提交读:允许事务读取另一个事务以前读取(未修改)的数据,而不必等待第一个事务完成。 数据库引擎保留写锁(在所选数据上获取)直到事务结束,但是一执行 SELECT 操作就释放读锁。 这是数据库引擎默认级别。
已提交读快照:与未提交读一样,不加锁,但在事务未提交时,不能读取刚修改的数据,而是读取事务修改前的数据。
nolock等同于未提交读
参考msdn 设置隔离级别

2)默认隔离级别是已提交读
3)设置隔离级别:
SET TRANSACTION ISOLATION LEVEL
{ READ UNCOMMITTED
| READ COMMITTED
| REPEATABLE READ
| SNAPSHOT
| SERIALIZABLE
}
[ ; ]
BEGIN TRAN

COMMIT

4)SELECT中设置NOLOCK,可以让mssql不去申请共享锁(S), 不过可能把没有提交事务的数据也显示出来,若之后事务回滚,select就会出现脏数据。

3,锁的类型:读锁(共享锁),申请修改锁(U),修改锁(X)
1共享(S):用于读取操作,如SELECT
2)更新(U):申请修改资源,做申请者登记,当资源释放时,可以第一个修改资源,它用于可更新的资源中,数据真正修改时再转化为排他锁。一次只有一个事务可以获得资源的更新锁(U 锁)。如果事务修改资源,则更新锁(U 锁)转换为排他锁(X 锁)。在已提交读级别以下(包含已提交读),因为共享锁在语句执行完之后就会释放,故先得到U锁的事务能接着转化为共享锁。在已提交读级别以上,更新锁作用不大,假设两个事务对同一资料都获取了共享锁,都执行更新操作,那么在事务结束前因都不会释放,故U锁将一直等待,转化不成排它锁进行修改,故会出现死锁。

3)排他(X):用于数据修改操作,如INSERT,UPDATE,DELETE
4)意向(I):用于建立锁的层次,一般是父层次,它有三种类型,意向共享(IS),意向排他(IX),意向排他共享(ISX)。
5)架构(SCH):包含两种类型,架构修改(Sch-M),架构稳定(Sch-S)
6)大容量更新。
7)键范围。
注:意向锁,锁定表或页,用它可以提高性能。原因:假设去桃花源景点,规定只有桃花源内无游客是,才允许下一位游客进入。现在来了一位新游客,判断是否他应该进入景点。方法有二:1,派景区管理员进入桃花源,在景区的山山水水排查,全部排查一遍,若无游客,则安排下一游客进入,若有,则下一游客等待。2,当前一游客进入时,将景区是否有游客进入状态设为TRUE,否则为False,那么当下一游客申请进入景区是,可以非常容易的判断出是否可以进入。 由这个问题知,方法2性能高一些。意向锁就相当于这个作用,当查询数据时,将数据所在的页或表设置为再用,以避免申请其他锁时的大范围判断。故知:意向锁可以提高性能,因为数据库引擎仅在表级检查意向锁,确定事务是否能安全的获取该表上的锁,而不需要检查表上的每行或每页。

8)锁与锁的申请:读与修改互斥,即若资源上现有共享锁,那么不能加排它锁,可加读锁,申请修改锁。若资源上有修改锁(X),那么不能读,也不能申请申请修改锁(U),换句话说,S锁与U锁是相互兼容的,但都与X锁不兼容。

9)可以加锁的资源分类:(1)RID,用于锁定堆上的某一行。(2)KEY:索引上的一行,或某个索引键。(3):数据页或索引页。(4):包含所有数据和索引的整个表。(5):DATABASE:整个数据库

时间: 2024-10-27 06:34:37

阻塞与死锁的相关文章

数据库阻塞和死锁的区别

本文来自:http://blog.sina.com.cn/s/blog_6f33ee7901018nsd.html 数据库阻塞和死锁在程序开发过程经常出现,怎么样避免呢?下面通过Demo简单模拟下,数据库发生阻塞和死锁的现象:一.数据库阻塞:    数据库阻塞的现象:第一个连接占有资源没有释放,而第二个连接需要获取这个资源.如果第一个连接没有提交或者回滚, 第二个连接会一直等待下去,直到第一个连接释放该资源为止.对于阻塞,数据库无法处理,所以对数据库操作要及时地提交或 者回滚.Demo:--创建

阻塞与死锁(一)——基础知识

原文:阻塞与死锁(一)--基础知识 阻塞与死锁是除内存.CPU.IO外另一个影响性能的因素.对OLTP系统尤为严重 一般以下问题是死锁的征兆: 1.  并发用户少的时候,一切正常,但是随着用户数量增多,性能越来越慢. 2.  客户端经常收到以下错误: Error 1222:Lock request time out period exceeded.(已超过锁请求超时时段) Error 1205:Your transaction(process ID #XX) was deadlocked on{

阻塞与死锁(二)——各种操作对锁的申请

原文:阻塞与死锁(二)--各种操作对锁的申请 如何监视锁的申请.持有和释放: 在着手分析.处理阻塞.死锁之前,首先要进行"监控"和"信息收集" 1.检查一个连接当前所持有的锁: 可以使用sp_lock来查看所有连接持有的锁的内容. 在2005以后引入的DMV,还能用过sys.dm_tran_locks来查看: SELECT request_session_id, resource_type , resource_associated_entity_id , requ

阻塞与死锁(三)——死锁的定位及解决方法

原文:阻塞与死锁(三)--死锁的定位及解决方法 死锁所在的资源和检测: 在SQL Server的两个或多个任务中,如果某个任务锁定了其他任务试图锁定的资源.会造成这些任务的永久阻塞,从而出现死锁. 下图为例: l  事务T1获得了行R1的共享锁. l  事务T2获得了行R2的共享锁. l  然后事务T1请求行R2的排它锁,但是T2完成并释放其对R2的共享锁之前被阻塞. l  T2请求行R1的排它锁,但是事务T1完成并释放其对R1持有的共享锁之前被阻塞. 现在T2与T1相互等待,导致了死锁.一般情

译码阻塞和死锁的等待资源

译码阻塞和死锁的等待资源 常用等待资源介绍 以下表格列出了常用等待资源的格式和意义. Resource Format Example Table DatabaseID:ObjectID:IndexID TAB: 5:261575970:1           In this case, database ID 5 is the pubs sample database and object ID 261575970 is the titles table and 1 is the cluster

查看数据库里阻塞和死锁情况

/*********************************** //删除 死锁 存储过程 ***************************************/ if exists (select * from dbo.sysobjects where id = object_id(N'[dbo].[sp_who_lock]') and OBJECTPROPERTY(id, N'IsProcedure') = 1) drop procedure [dbo].[sp_who_l

第十六章——处理锁、阻塞和死锁(3)——使用SQLServer Profiler侦测死锁

原文:第十六章--处理锁.阻塞和死锁(3)--使用SQLServer Profiler侦测死锁 前言: 作为DBA,可能经常会遇到有同事或者客户反映经常发生死锁,影响了系统的使用.此时,你需要尽快侦测和处理这类问题. 死锁是当两个或者以上的事务互相阻塞引起的.在这种情况下两个事务会无限期地等待对方释放资源以便操作.下面是死锁的示意图: 本文将使用SQLServer Profiler来跟踪死锁. 准备工作: 为了侦测死锁,我们需要先模拟死锁.本例将使用两个不同的会话创建两个事务. 步骤: 1. 打

第十六章——处理锁、阻塞和死锁(2)——侦测阻塞和阻塞查询

原文:第十六章--处理锁.阻塞和死锁(2)--侦测阻塞和阻塞查询 前言: 如果一个事务正在等待一些给其他事务锁定的资源.这个事务就被成为"被阻塞的事务".反过来,引起阻塞的事务,也就是锁定资源并造成其他事务等待的事务叫做"正在阻塞的事务". 长时间运行事务会阻塞其他事务和查询,使他们等待长时间.在繁重的系统中,很多时候我们会遇到阻塞问题,如果一个事务因为阻塞未完成.会造成一些列的等待链. 本文将介绍如何发现并马上解决这方面的问题. 准备工作: 本例依旧使用SQLSe

第十六章——处理锁、阻塞和死锁(1)——确定长时间运行的事务

原文:第十六章--处理锁.阻塞和死锁(1)--确定长时间运行的事务 前言: 事务是OLTP系统中的主要部分.它管理数据一致性和数据并发问题,当多个资源同时被读取或者修改相同数据时,SQLServer会通过锁定机制来确保数据库中的数据总是处于一个有效状态.在SQLServer中,锁管理器是负责实现这些锁机制.SQLServer对于不同的资源类型提供不同的锁类型,如数据库.文件.对象.表.区.页和键. 当你使用事务时,依然会遇到由事务引起的问题,这些通常是由于锁.阻塞和死锁引起的. 本系列将讲解这三

锁的种类,阻塞,死锁产生与解决办法。

TM锁的种类: TM锁几种模式的互斥关系: 阻塞 定义:当一个会话保持另一个会话正在请求的资源上的锁定时,就会发生阻塞.被阻塞的会话将一直挂起,直到持有锁的会话放弃锁定的资源为止.4个常见的dml语句会产生阻塞INSERTUPDATEDELETESELECT-FOR UPDATE -------------------------------------------------------------- update 的阻塞     试验: 1.    获得会话sid SQL> select s