db并发控制_notes
来源:未知 责任编辑:智问网络 发表时间:2013-11-08 08:50 点击:次
·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)检测事务等待图,如果发现图中存在回路,则表示系统中出现了死锁。
·死锁的解除
·选择一个处理死锁代价最小的事务,将其撤消,释放此事务持有的所有的锁,使其它事务能继续运行下去。
·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)检测事务等待图,如果发现图中存在回路,则表示系统中出现了死锁。
·死锁的解除
·选择一个处理死锁代价最小的事务,将其撤消,释放此事务持有的所有的锁,使其它事务能继续运行下去。
最新推荐更多>>>
- 发表评论
-
- 最新评论 更多>>