db并发控制_notes

 
·11.1 并发控制概述11.2 封锁(Locking)
·11.3 活锁和死锁
·11.4 并发调度的可串行性
·11.5 两段锁协议
·11.6 封锁的粒度
 
 
 
 
11.1 并发控制概述11.2 封锁(Locking)
 
·多事务执行方式 :
·(1)事务串行执行
·(2)交叉并发方式
·(3)同时并发方式
 
·并发操作带来的数据不一致性:
·丢失修改(lost update)
·不可重复读(non-repeatable read)
·读“脏”数据(dirty read)
 
·并发控制的主要技术:
·封锁(Locking)   (商用的DBMS一般都采用封锁方法)
·时间戳(Timestamp)
·乐观控制法
 
·基本封锁类型:
· 排它锁(Exclusive lock,简记为X锁)
·共享锁(Share lock,简记为S锁)
 
·封锁协议(Locking Protocol)
·常用的封锁协议:三级封锁协议。
 
 
·一级封锁协议
·事务T在修改数据R之前必须先对其加X锁,直到事务结束才释放。
·一级封锁协议可防止丢失修改
·在一级封锁协议中,如果是读数据,是不需要加锁的,所以它不能避免不可重复读和读“脏”数据。
·二级封锁协议
·一级封锁协议+事务T在读取数据R前必须先加S锁,读完后不等事务结束即可释放S锁。
·二级封锁协议可以防止丢失修改和读“脏”数据。
·在二级封锁协议中,由于读完数据后即可释放S锁,所以它不能避免不可重复读。
·三级封锁协议
·三级封锁协议 + 事务T在读取数据R之前必须先对其加S锁,直到事务结束才释放
·三级封锁协议可避免丢失修改、读“脏”数据和不可重复读。
 
 
 
 
 
SQLServer的并发机制
· 事务隔离
·对于 编程人员来说,不用手工去设置控制锁,通过设置事务的隔离级别自动管理锁。
 

隔离级别

脏读

丢失修改(虚读)

不可重复读取

幻影(不可重复读取的两种情况)

未提交读

不能避免

不能避免

不能避免

不能避免

提交读

能避免

不确定

不能避免

不能避免

可重复读

能避免

能避免

能避免

不能避免

可串行读

能避免

能避免

能避免

能避免

 
 
 
 
·SET TRANSACTION ISOLATION LEVEL
·READ UNCOMMITTED
·READ COMMITTED
·REPEATABLE READ
·SERIALIZABLE
 
 
 
 
 
 
 
 
 
 
 
活锁和死锁
 
避免活锁
采用先来先服务的策略(队列)
解决死锁
·1. 采取一定措施预防死锁的发生。
2. 允许死锁发生,采取一定方法诊断死锁、解除死锁。
 
·死锁的预防
·一次封锁法
·要求每个事务必须一次将所有要使用的数据全部加锁,否则就不能继续执行
·一次封锁法存在的问题:
·将以后要用到的全部数据加锁,势必扩大了封锁的范围,从而降低了系统的并发度。
·顺序封锁法:
·预先对数据对象规定一个封锁顺序,所有事务都按这个顺序实行封锁。
·顺序封锁法存在的问题
·数据库系统中可封锁的数据对象极其众多,而且还在不断变化,要维护这样极多而且变化的资源的封锁顺序非常困难,成本很高。
事务的封锁请求可以随着事务的执行而动态地决定,很难事先确定每一个事务要封锁哪些对象,因此也就很难按规定的顺序去施加封锁。
 
·死锁的诊断
·超时法:
·如果一个事务的等待时间超过了规定的时限,就认为发生了死锁
·优点:实现简单
·缺点
·有可能误判死锁。
·时限若设置得太长,死锁发生后不能及时发现。
·等待图法:
·用事务等待图动态反映所有事务的等待情况
·事务等待图是一个有向图G=(T,U)
·并发控制子系统周期性地(比如每隔1min)检测事务等待图,如果发现图中存在回路,则表示系统中出现了死锁。
 
·死锁的解除
·选择一个处理死锁代价最小的事务,将其撤消,释放此事务持有的所有的锁,使其它事务能继续运行下去。
 
 
 
 
 
 
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

折腾数据折腾代码

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值