(转)http://zhuyuehua.iteye.com/blog/1123340
为了得到最大的性能,一般数据库都有并发机制,不过带来的问题就是数据访问的冲突。为了解决这个问题,大多数数据库用的方法就是数据的锁定。
考虑下面的情况。如果我们先查询到数据,然后更新数据。这样会出现这样的情况。A线程查询的时候,B线程也在查询,当A线程准备更新的时候,B线程先获得了更新锁,将这些行锁定了。A只能等待B更新完。当B线程更新完释放锁的时候,A获得锁,这时A会识别出字段已经修改,所以会重新查询数据,然后开始更新。
这在数据库中本来是没什么问题的。但应用程序中会出现一个问题。假如有一个修改商品信息的页面
A,打开这个页面,得到商品数据。有编号 ,名称 ,价格。
B,也打开这个页面,得到商品数据。有编号 ,名称 ,价格。
然后A修改商品的价格,然后点保存。
B修改商品的名称,点保存。
这里有一个问题是,当A保存修改后的商品价格时,他实际上保存了原编号,原名称,修改后价格。
然后B再点保存的时候,他实际上保存了原编号,修改后的名称,原价格。
这样,B的修改就将A的修改覆盖了。导致A的修改无效。
那么,怎么解决这种问题呢。、?
这里有两种方法解决这个问题,也就是所谓的乐观锁和悲观锁。
悲观锁
锁在用户修改之前就发挥作用:
Select ..for update(nowait)
Select * from tab1 for update
用户发出这条命令之后,oracle将会对返回集中的数据建立行级封锁,以防止其他用户的修改。
如果此时其他用户对上面返回结果集的数据进行dml或ddl操作都会返回一个错误信息或发生阻塞
悲观锁是这样实现的。
当查询到商品信息,并试图更新数据时,在查询的语句后加上for update nowait
这表示当A从准备更新这个数据(查询这个数据并显示到页面上)开始,这个数据就被锁定了,当你更新完成,才释放锁。
当B也准备更新这个数据时,因为有for update nowait,查询这个数据时并显示到页面上就会出错。所以不会更新。
这样就能保证每次只有一个准备更新的连接。从而就保证了数据不会出现丢失更新
悲观锁假定其他用户企图访问或者改变你正在访问、更改的对象的概率是很高的,因此在悲观锁的环境中,在你开始改变此对象之前就将该对象锁住,并且直到你提交了所作的更改之后才释放锁。悲观的缺陷是不论是页锁还是行锁,加锁的时间可能会很长,这样可能会长时间的限制其他用户的访问,也就是说悲观锁的并发访问性不好。
也就是说,当我们找到需要更改的对象时,就把这些行锁定,只能让我修改。当我修改完成时,再释放这个锁,别人才能修改。这样就能防止我找到需要更改的对象到我开始更新数据这段时间内,其他线程获得锁先更新数据的情况。
乐观锁
乐观的认为数据在select出来到update进取并提交的这段时间数据不会被更改。这里面有一种潜在的危险就是由于被选出的结果集并没有被锁定,
是存在一种可能被其他用户更改的可能。因此Oracle仍然建议是用悲观封锁,因为这样会更安全
乐观锁是这样实现的。
每次更新时都和旧版本的数据比较。具体如下:
A,打开这个页面,得到商品数据。有编号 ,名称 ,价格。
B,也打开这个页面,得到商品数据。有编号 ,名称 ,价格。
然后A修改商品的价格,然后点保存。这时更新语句是这样的
set 编号 = 原编号 ,名称 = 原名称 ,价格 =新价格 where 编号 = 原编号 ,名称 = 原名称 ,价格 =原价格
因为A更新时满足WHERE后条件,所以更新成功。
当B修改商品的名称,点保存。语句是这样的
set 编号 = 原编号 ,名称 = 新名称 ,价格 =原价格 where 编号 = 原编号 ,名称 = 原名称 ,价格 =原价格
此时价格已经是新的价格,所以价格(新价格) = 原价格 条件不满足,所以更新不成功。
这样就避免了丢失更新。
每个数据都和旧数据比较,可能比较麻烦,可以专门建一列,用作版本列。
当更新一次时,版本列数据加1。这样
然后A修改商品的价格,然后点保存。这时更新语句是这样的
set 编号 = 原编号 ,名称 = 原名称 ,价格 =新价格 ,版本 = 版本 + 1 where 编号 = 原编号 ,版本 = 版本
因为A更新时满足WHERE后条件,所以更新成功。
当B修改商品的名称,点保存。语句是这样的
set 编号 = 原编号 ,名称 = 新名称 ,价格 =原价格 ,版本 = 版本 + 1 where 编号 = 原编号 ,版本 = 版本
此时价格已经是新的版本 ,所以版本 (新版本 ) = 原版本 条件不满足,所以更新不成功。
这里的版本号也可以采用时间戳类型,这样可以顺便看到该行最后更新的时间。
(
采用时间戳类型和第二种版本比较有点类似,就是也新增一个Table的Column,不过这次这个column是采用timestamp型,存储数据最后更新的时间。在Oracle9i以后可以采用新的数据类型,也就是timestamp with time zone类型来做时间戳。这种Timestamp的数据精度在Oracle的时间类型中是最高的,精确到微秒(还没与到纳秒的级别),一般来说,加上数据库处理时间和人的思考动作时间,微秒级别是非常非常够了,其实只要精确到毫秒甚至秒都应该没有什么问题。和刚才的版本戳类似,也是在更新提交的时候检查当前数据库中数据的时间戳和自己更新前取到的时间戳进行对比,如果一致则OK,否则就是版本冲突。如果不想把代码写在程序中或者由于别的原因无法把代码写在现有的程序中,也可以把这个时间戳乐观锁逻辑写在Trigger或者存储过程中
)
乐观锁则认为其他用户企图改变你正在更改的对象的概率是很小的,因此乐观锁直到你准备提交所作的更改时才将对象锁住,当你读取以及改变该对象时并不加锁。可见乐观锁加锁的时间要比悲观锁短,乐观锁可以用较大的锁粒度获得较好的并发访问性能。但是如果第二个用户恰好在第一个用户提交更改之前读取了该对象,那么当他完成了自己的更改进行提交时,数据库就会发现该对象已经变化了,这样,第二个用户不得不重新读取该对象并作出更改。这说明在乐观锁环境中,会增加并发用户读取对象的次数。
死锁-deadlock
定义:当两个用户希望持有对方的资源时就会发生死锁.
即两个用户互相等待对方释放资源时,oracle认定为产生了死锁,在这种情况下,将以牺牲一个用户作为代价,另一个用户继续执行,牺牲的用户的事务将回滚.
例子:
1:用户1对A表进行Update,没有提交。
2:用户2对B表进行Update,没有提交。
此时双反不存在资源共享的问题。
3:如果用户2此时对A表作update,则会发生阻塞,需要等到用户一的事物结束。
4:如果此时用户1又对B表作update,则产生死锁。此时Oracle会选择其中一个用户进行会滚,使另一个用户继续执行操作。
起因:
Oracle的死锁问题实际上很少见,如果发生,基本上都是不正确的程序设计造成的,经过调整后,基本上都会避免死锁的发生。
DML锁分类表
表1 Oracle的TM锁类型 | |||
锁模式 | 锁描述 | 解释 | SQL操作 |
0 | none | ||
1 | NULL | 空 | Select |
2 | SS(Row-S) | 行级共享锁,其他对象只能查询这些数据行 | Select for update、Lock for update、Lock row share |
3 | SX(Row-X) | 行级排它锁,在提交前不允许做DML操作 | Insert、Update、Delete、Lock row share |
4 | S(Share) | 共享锁 | Create index、Lock share |
5 | SSX(S/Row-X) | 共享行级排它锁 | Lock share row exclusive |
6 | X(Exclusive) | 排它锁 | Alter table、Drop able、Drop index、Truncate table 、Lock exclusive |
1.关于V$lock表和相关视图的说明
2.其它相关视图说明
视图名 | 描述 | 主要字段说明 |
v$session | 查询会话的信息和锁的信息。 | sid,serial#:表示会话信息。 program:表示会话的应用程序信息。 row_wait_obj#:表示等待的对象,和dba_objects中的object_id相对应。 lockwait :该会话等待的锁的地址,与v$lock的kaddr对应. |
v$session_wait | 查询等待的会话信息。 | sid:表示持有锁的会话信息。 Seconds_in_wait:表示等待持续的时间信息 Event:表示会话等待的事件,锁等于enqueue |
dba_locks | 对v$lock的格式化视图。 | Session_id:和v$lock中的Sid对应。 Lock_type:和v$lock中的type对应。 Lock_ID1: 和v$lock中的ID1对应。 Mode_held,mode_requested:和v$lock中 的lmode,request相对应。 |
v$locked_object | 只包含DML的锁信息,包括回滚段和会话信息。 | Xidusn,xidslot,xidsqn:表示回滚段信息。和 v$transaction相关联。 Object_id:表示被锁对象标识。 Session_id:表示持有锁的会话信息。 Locked_mode:表示会话等待的锁模式的信 息,和v$lock中的lmode一致。 |
1.查询数据库中的锁
select * from v$lock;
select * from v$lock where block=1;
2.查询被锁的对象
select * from v$locked_object;
3.查询阻塞
查被阻塞的会话
select * from v$lock where lmode=0 and type in ('TM','TX');
查阻塞别的会话锁
select * from v$lock where lmode>0 and type in ('TM','TX');
4.查询数据库正在等待锁的进程
select * from v$session where lockwait is not null;
5.查询会话之间锁等待的关系
select a.sid holdsid,b.sid waitsid,a.type,a.id1,a.id2,a.ctime from v$lock a,v$lock b
where a.id1=b.id1 and a.id2=b.id2 and a.block=1 and b.block=0;