Oracle数据库的锁类型
根据保护的对象不同,Oracle数据库锁可以分为以下几大类：DML锁（data locks,数据锁）,用于保护数据的完整性；DDL锁（dictionary locks,字典锁）,用于保护数据库对象的结构,如表、索引等的结构定义；内部锁和闩（internal locks and latches）,保护数据库的内部结构.
DML锁的目的在于保证并发情况下的数据完整性,本文主要讨论DML锁.在Oracle数据库中,DML锁主要包括TM锁和TX锁,其中TM锁称为表级锁,TX锁称为事务锁或行级锁.
在数据行上只有X锁（排他锁）.在 Oracle数据库中,当一个事务首次发起一个DML语句时就获得一个TX锁,该锁保持到事务被提交或回滚.当两个或多个会话在表的同一条记录上执行DML语句时,第一个会话在该条记录上加锁,其他的会话处于等待状态.当第一个会话提交后,TX锁被释放,其他会话才可以加锁.
TX锁等待的分析
在介绍了有关地Oracle数据库锁的种类后,下面讨论如何有效地监控和解决锁等待现象,及在产生死锁时如何定位死锁的原因.
TX锁等待的监控和解决在日常工作中,如果发现在执行某条SQL时数据库长时间没有响应,很可能是产生了TX锁等待的现象.为解决这个问题,首先应该找出持锁的事务,然后再进行相关的处理,如提交事务或强行中断事务.
死锁的监控和解决在数据库中,当两个或多个会话请求同一个资源时会产生死锁的现象.死锁的常见类型是行级锁死锁和页级锁死锁,Oracle数据库中一般使用行级锁.下面主要讨论行级锁的死锁现象.
如果查询结果表明,死锁是由于bitmap索引引起的,将IND_T_PRODUCT_HIS_STATE索引改为normal索引后,即可解决死锁的问题.
表1 Oracle的TM锁类型
锁模式 锁描述 解释 SQL操作
0 none
①. NULL 空 Select
视图名 描述 主要字段说明
v$session 查询会话的信息和锁的信息. sid,serial#：表示会话信息.
program：表示会话的应用程序信息.
row_wait_obj#：表示等待的对象.
和dba_objects中的object_id相对应.
v$session_wait 查询等待的会话信息. sid：表示持有锁的会话信息.
Seconds_in_wait：表示等待持续的时间信息
Event：表示会话等待的事件.
v$lock 列出系统中的所有的锁. Sid：表示持有锁的会话信息.
Type：表示锁的类型.值包括TM和TX等.
ID1：表示锁的对象标识.
lmode,request：表示会话等待的锁模式的信
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一致.
select b.owner,b.object_name,l.session_id,l.locked_mode
from v$locked_object l, dba_objects b
where b.object_id=l.object_id;
如果有长期出现的一列,可能是没有释放的锁.我们可以用下面SQL语句杀掉长期没有释放非正常的锁：
alter system kill session 'sid,serial# ';
如果出现了锁的问题, 某个DML操作可能等待很久没有反应.
数据库与操作系统一样,是一个多用户使用的共享资源. 当多个用户并发地存取数据时,在数据库中就会发生多个事务同时存取同一数据地情况. 若对并发操作不加控制就可能会读取和存储不正确地数据,破坏数据库地一致性. 加锁时实现数据库并发控制地一个非常重要地技术. 在实际应用中经常会遇到地与锁相关地异常情况,当两个事务需要一组有冲突的锁,而不能将事务继续下去的话,就会出现死锁,严重影响应用的正常执行.
在数据库中有两种基本的锁类型：排它锁（Exclusive Locks,即X锁）和共享锁（即S锁）.当数据对象被加上排它锁时,其他的事务不能不能对它读取和修改.加了共享锁的数据对象可以被其他事务读取,但不能修改.数据库利用这两种基本的锁类型来对数据库的事务进行并发控制.
死锁的第一种情况：
一个用户A访问表A（锁住了表A）,然后又访问表B； 另一个用户B访问表B（锁住了表B）,然后企图访问表A；这时用户A由于用户B已经锁住表B,它必须等待用户B释放表B才能继续,同样用户B要等用户A释放表A才能继续,这就死锁产生了.
解决方法：
这种死锁比较常见,是由于程序的BUG产生的,除了调整程序的逻辑没有其它的办法.仔细分析程序的逻辑,对于数据库的多表操作时,尽量按照同样的顺序进行处理,尽量避免同时锁定两个资源,如操作A和B两张表时,总是按先A后B的顺序处理,必须同时锁定两个资源时,要保证在任何时刻都应该按照相同的顺序来锁定资源.
死锁的第二种情况
死锁的第三种情况
如果在事务种执行了一条不满足条件的update语句,则执行全表扫描,把行级锁上升为表级锁,多个这样的事务执行之后,就很容易发生死锁和阻塞.类似的情况还有当表种的数据量非常庞大而索引建的过少或不合适的时候,使得经常发生全表扫描,最终应用系统会越来越慢,最终发生阻塞或死锁.
SQL语句中不要使用太复杂的关联多表的查询；使用"执行计划"对SQL语句进行 分析,对于有全表扫描的SQL语句,建立相应的索引进行优化.
***查询死锁表以及解锁表***
通过select * from v$locked_object
可以获得被锁的对象的object_id及产生锁的会话sid,通过查询结果中的object_id,可以查询到具体被锁的对象.
锁有以下几种模式:
0：none
①.：null 空
数字越大锁级别越高, 影响的操作越多.
当对话使用for update子串打开一个游标时,
所有返回集中的数据行都将处于行级(Row-X)独占式锁定,
其他对象只能查询这些数据行,不能进行update、delete或select...for update操作.
没有commit之前插入同样的一条记录会没有反应,
以DBA角色, 查看当前数据库里锁的情况可以用如下SQL语句：
select object_id,session_id,locked_mode from v$locked_object;
如果有长期出现的一列,可能是没有释放的锁.
我们可以用下面SQL语句杀掉长期没有释放非正常的锁：
户A打开应用的界面,看到数据库的某条记录
b.用户B打开应用的界面,看到同样一条记录
c. 用户A对记录做了修改
d. 对于web应用而言[假设没有应用comet类似技术],通常B不知道这个修改,这时B也对同样这条记录做修改,那B就有可能覆盖A做的修改;
这个问题在数据库中被称为丢失更新问题
a. 不知道这个问题
我在做开发好长时间之后才意识到这个问题,意识到这个问题之后,我后来发现很长一段时间内都没真正搞明白为什么这是个问题-_- 而且我发现现在周围的很多同事,尤其是新毕业的学生,其实也一直过了很长时间都没明白这个问题,这说明吧不知道这个丢失更新问题是一个非常普遍的问题：)
b.用信号量以及操作之前再次验证的方法解决
然后用来控制这个操作,每次操作前获取信号量,然后验证,再做真正的数据库操作...相当于在应用层每次都只做一件事.
c. 再次理解
但是其实我有个疑问,对于数据库中的记录而言,A做的修改本来就有可能被B覆盖的,为什么这会是一个丢失更新问题呢? 正好项目里面又出现了类似的情况,我仔细观察了下,终于明白为什么这是个问题,以及为什么要使用对应的乐观锁悲观锁方案了.下面对此做详细说明
下面这个假设的实际场景可以比较清楚的帮助我们理解这个问题：
假设当当网上用户下单买了本书,这时数据库中有条订单号为001的订单,其中有个status字段是'有效',表示该订单是有效的;
后台管理人员查询到这条001的订单,并且看到状态是有效的
用户发现下单的时候下错了,于是撤销订单,假设运行这样一条SQL: update order_table set status = '取消' where order_id = 001;
如果当当的系统这样实现,显然不对了,肯定要挨骂了,明明已经取消了订单,为什么还会发货呢?而且确实取消订单的操作发生在发货操作之前啊. 因为在这样的实现下,后台管理人员无论怎么做都有可能会出错,因为他打开系统看到有效的订单和他点发货之间肯定有个时间差,在这个时间差的时候总是存在用户取消订单的可能.
① 获取一个信号量,保证每次只能有一个线程进入下面的步骤
a. 如果有效则继续,进入发货步骤 b) 如果无效则返回,释放信号量,告诉用户状态已经发生改变
问题清楚了,也说明了我曾经使用的解决方案也是一个简洁直接的解决方案,纯粹是把简单问题复杂化,下面说说实际有效的解决方案; 就这个丢失更新问题,可以通过数据库的锁来实现,基本两种思路,一种是悲观锁,另外一种是乐观锁; 简单的说就是一种假定这样的问题是高概率的,最好一开始就锁住,免得更新老是失败;另外一种假定这样的问题是小概率的,最后一步做更新的时候再锁住,免得锁住时间太长影响其他人做有关操作;
这里先说web开发中常用的乐观锁的方法：
①很简单,就是使用前面所说的这样一条SQL,这其实是所谓使用"前镜像"的方式来保证需要更新的数据是符合要求的,
这个方法比较简单,也最常用,就是在数据库表格中加一列last_modified_date,就是最后更新的时间,每次更新的时候都将这列设成systimestamp,当前系统时间;
然后每次更新的时候,就改成这样 Update table set col = newvalue where id = ** and last_modified_date = old last_modified_date 这样,就可以检验出数据库的值是否在上次查看和这次更新的时候发生了变化,如果发生了变化,那么last_modified_date就变化了,以后的更新就会返回更新了0行,系统就可以通知用户数据发生了变化,然后选择刷新数据或者其他流程.
至于这个last_modified_date的维护,可以选择让应用每次都维护这个值,或者是使用存储过程来包装更新的操作,或者是使用触发器来更新相关的值.几种方法各有利弊,比如应用维护需要保证每段相关代码都正确的维护了这个值;存储过程有一定的开销,通常很多开发对写存储过程可能也不熟练;触发器是简单的实现,但是也是有开销的.具体使用哪种方法需要根据实际情况具体取舍.
这种方法和前面的方法类似,无非是根据其他有实际意义的列来计算出一个虚拟的列,我个人觉得TOM在介绍这个纯粹是介绍了一种"奇技淫巧",反正我是在实际过程中不知道哪里会需要这样的解决方案,或许也是因为我知道的太少了吧：)
这个就是利用10g的一个ora_rowscn特性,可以对每行做精确追踪,不过这个要求在create table的时候就指定相关参数,表格如果创建了以后就不能用alter table来修改了,因为这依赖于物理的实际存储. 同样,我觉得这也可以归为"奇技淫巧"一类; 具体如果有兴趣了解详情的话,可以参考Tom的书
微信公众号
TechTarget
官方微博
TechTarget中国
相关资源：oracle乐观锁和悲观锁详细教程_oracle的乐观锁-Oracle文档类资源...
打开CSDN,阅读体验更佳
Oracle数据库悲观锁与乐观锁_diweikang的博客
注:对于悲观锁是针对并发的可能性比较大,而一般在我们的应用中用乐观锁足以. Oracle的悲观锁需要利用一条现有的连接,分成两种方式,从SQL语句的区别来看,就是一种是for update,一种是for update nowait的形式. 1. 执行select xxx ...
oracle 乐观锁和悲观锁详细教程
详细介绍了Oracle中乐观锁、悲观锁的原理及应用,并有实例
基于ORACLE的乐观锁实现原理
继续访问
根据保护的对象不同,Oracle数据库锁可以分为以下几大类:DML锁(data locks,数据锁),用于实现并发存取并保护数据的完整性;DDL锁(dictionary locks,字典锁),用于保护数据库对象的结构,如表、索引等的结构定义;内部锁和闩(internal locks ...
oracle乐观锁和悲观锁详细教程_oracle的乐观锁-Oracle文档类资源...
Oracle创建悲观锁和乐观锁
为了得到最大的性能,一般数据库都有并发机制,不过带来的问题就是数据访问的冲突.为了解决这个问题,大多数数据库用的方法就是数据的锁定. 考虑下面的情况.如果我们先查询到数据,然后更新数据.这样会出现这样的情况.A线程查询的时候,B线程也在查询,当A线程准备更新的时候,B线程先获得 了更新锁,将这些行锁定了.A只能等待B更新完.当B线程更新完释放锁的时候,A获得锁,这时A会识别出字段已经
Oracle并发控制中的乐观锁
oracle乐观锁悲观锁学习笔记(更新中)_Evaron.Z的博客
首先解释下乐观锁和悲观锁的含义 乐观锁:乐观锁就是认为数据一般情况下不会造成冲突,所以在数据进行提交更新的时候,才会正式对数据的冲突与否进行检测,如果发现冲突了,则返回错误的信息. 悲观锁:悲观锁就是对数据的冲突采取一种悲观的...
【Oracle】乐观锁和悲观锁_◣NSD◥的博客_oracle悲观锁...
乐观锁对应于生活中乐观的人总是想着事情往好的方向发展,悲观锁对应于生活中悲观的人总是想着事情往坏的方向发展.这两种人各有优缺点,不能不以场景而定说一种人好于另外一种人. 悲观锁 ...
Oracle乐观锁悲观锁
【转】 Oracle中乐观锁定的四种实现方式
br /Oracle中乐观锁定的四种实现方式br / br /转自 ;br / 更新前在应用中存储所要操作行的"前映像",更新时使用存储的旧记录来判断当前值是否已经改变； 使用一个特殊的列,这个列由一个数据库触发器或应用程序代码维护,可以告诉我们记录的 "版本"； 使用一个校验和或散列值,这是使用原来的数据计算得出的； 使用新增的 Oracle 10g 特性 ORA_R
oracle的悲观锁和乐观锁
Oracle的悲观锁和乐观锁
为了得到最大的性能,一般数据库都有并发机制,不过带来的问题就是数据访问的冲突.为了解决这个问题,大多数数据库用的方法就是数据的锁定. 数据的锁定分为两种方法,第一种叫做悲观锁,第二种叫做乐观锁.什么叫悲观锁呢,悲观锁顾名思义,...
oracle锁机制之悲观锁与乐观锁以及for update用法
oracle的乐观锁和悲观锁
第一段：问题引出 ① 假设当当网上用户下单买了本书,这时数据库中有条订单号为001的订单,其中有个status字段是'有效',表示该订单是有效的； ② 后台管理人员查询到这条001的订单,并且看到状态是有效的； ③ 用户发现下单的时候下错了,于是撤销订单,假设运行这样一条SQL: update order_table set status = '取消' whe
Oracle锁定：悲观与乐观锁详解
Oracle数据库悲观锁与乐观锁是本文我们主要要介绍的内容.有时候为了得到最大的性能,一般数据库都有并发机制,不过带来的问题就是数据访问的冲突.为了解决这个问题,大多数数据库用的方法就是数据的锁定...... 以下是代码片段： select*fromtestwhereid=10也就是没有for update这种锁定数据的语句的话,就不会造成阻塞了.另外一种情况,就是当数据库数据被锁定的时候,也
乐观锁与悲观锁——解决并发问题
乐观锁和悲观锁策略的区别与实现
乐观锁和悲观锁策略的区别与实现 1、无论是选择悲观锁策略,还是乐观锁策略.如果一个对象被上了锁,那么该对象都会受这个锁的控制和影响.如果这个锁是个排它锁,那么其它会话都不...
oracle的共享锁不起作用,ORACLE中的乐观锁、悲观锁、共享锁、排他锁
oracle 锁定 问题
锁（lock）机制用于管理对共享资源的并发访问. 数据库中使用锁是为了支持对共享资源进行并发访问,与此同时还能提供数据完整性和一致性. 在Oracle中,你会了解到： ? 事务是每个数据库的核心,它们是"好东西". ? 应该延迟到适当的时刻才提交.不要太快提交,以避免对系统带来压力.这是因为,如果事务很长或很大,一般不会对系统有压力.相应的原则是：在必要时才提交,但是此前不要提
最新发布 oracle数据库加悲观锁,Oracle 悲观锁跟乐观锁
Oracle 乐观锁、悲观锁
oracle有悲观锁也有乐观锁. 悲观锁比较安全一些,可以防止丢失更新,但是就是互相等待,影响效率. 一般会用乐观锁,即开始操作时,乐观的认为数据不会被其他人更改,直到提交时才加锁检查.比如在操作的表上加一列,保存个时间戳,提交时检查是不是最新的.不过乐观锁失败的可能性比较大. 乐观锁,大多是基于数据版本（ Version ）记录机制实现.
oracle乐观锁实例
oracle 悲观锁和乐观锁
写评论
评论
收藏
点赞
踩
分享
前往CSDN APP阅读全文
阅读体验更佳
CSDN
成就一亿技术人
前往
为了得到最大的性能,一般数据库都有并发机制,不过带来的问题就是数据访问的冲突.为了解决这个问题,大多数数据库用的方法就是数据的锁定.
数据的锁定分为两种方法,第一种叫做悲观锁,第二种叫做乐观锁.什么叫悲观锁呢,悲观锁顾名思义,就是对数据的冲突采取一种悲观的态度,也就是说假设数据肯定会冲突,所以在数据开始读取的时候就把数据锁定住.而乐观锁就是认为数据一般情况下不会造成冲突,所以在数据进行提交更新的时候,才会正式对数据的冲突与否进行检测,如果发现冲突了,则让用户返回错误的信息,让用户决定如何去做.
先从悲观锁开始说.在SqlServer等其余很多数据库中,数据的锁定通常采用页级锁的方式,也就是说对一张表内的数据是一种串行化的更新插入机制,在任何时间同一张表只会插1条数据,别的想插入的数据要等到这一条数据插完以后才能依次插入.带来的后果就是性能的降低,在多用户并发访问的时候,当对一张表进行频繁操作时,会发现响应效率很低,数据库经常处于一种假死状态.而Oracle用的是行级锁,只是对想锁定的数据才进行锁定,其余的数据不相干,所以在对Oracle表中并发插数据的时候,基本上不会有任何影响.
注：对于悲观锁是针对并发的可能性比较大,而一般在我们的应用中用乐观锁足以.
Oracle的悲观锁需要利用一条现有的连接,分成两种方式,从SQL语句的区别来看,就是一种是for update,一种是for update nowait的形式.比如我们看一个例子.首先建立测试用的数据库表.
CREATE TABLE TEST(ID,NAME,LOCATION,VALUE,CONSTRAINT test_pk PRIMARY KEY(ID))AS SELECT deptno, dname, loc, 1 FROM scott.dept
这里我们利用了Oracle的Sample的scott用户的表,把数据copy到我们的test表中.首先我们看一下for update锁定方式.首先我们执行如下的select for update语句.
select * from test where id = 10 for update
通过这条检索语句锁定以后,再开另外一个sql*plus窗口进行操作,再把上面这条sql语句执行一便,你会发现sqlplus好像死在那里了,好像检索不到数据的样子,但是也不返回任何结果,就属于卡在那里的感觉.这个时候是什么原因呢,就是一开始的第一个Session中的select for update语句把数据锁定住了.由于这里锁定的机制是wait的状态(只要不表示nowait那就是wait),所以第二个Session(也就是卡住的那个sql*plus)中当前这个检索就处于等待状态.当第一个session最后commit或者rollback之后,第二个session中的检索结果就是自动跳出来,并且也把数据锁定住.不过如果你第二个session中你的检索语句如下所示.
select * from test where id = 10
select * from test where id = 10 for update nowait
那这里另外一个问题,就是当我们锁定住数据的时候,我们对数据进行更新和删除的话会是什么样呢.比如同样,我们让第一个Session锁定住id=10的那条数据,我们在第二个session中执行如下语句.
这个时候我们发现update语句就好像select for update语句一样也停住卡今天这一节,当你第一个session放开锁定以后update才能正常运行.当你update运行后,数据又被你update语句锁定住了,这个时候只要你update后还没有commit,别的session照样不能对数据进行锁定更新等等.
常用的做法来实现.
[1]第一种就是在数据取得的时候把整个数据都copy到应用中,在进行提交的时候比对当前数据库中的数据和开始的时候更新前取得的数据.当发现两个数据一模一样以后,就表示没有冲突可以提交,否则则是并发冲突,需要去用业务逻辑进行解决.
时候再进行业务处理,比如整个Transaction都Rollback等等操作.在用版本戳的时候,可以在应用程序侧使用版本戳的验证,也可以在数据库侧采用Trigger(触发器)来进行验证.不过数据库的Trigger的性能开销还是比较的大,所以能在应用侧进行验证的话还是推荐不用Trigger.
不知道这个是不是你需要的...
以上就是土嘎嘎小编为大家整理的oracle怎么用乐观锁相关主题介绍,如果您觉得小编更新的文章只要能对粉丝们有用,就是我们最大的鼓励和动力,不要忘记讲本站分享给您身边的朋友哦！！