户A打开应用的界面,看到数据库的某条记录
b用户B打开应用的界面,看到同样一条记录
c 用户A对记录做了修改
d 对于web应用而言[假设没有应用comet类似技术],通常B不知道这个修改,这时B也对同样这条记录做修改,那B就有可能覆盖A做的修改;
这个问题在数据库中被称为丢失更新问题
2我自己对这个问题的理解过程是这样的:
a 不知道这个问题
我在做开发好长时间之后才意识到这个问题,意识到这个问题之后,我后来发现很长一段时间内都没真正搞明白为什么这是个问题-_- 而且我发现现在周围的很多同事,尤其是新毕业的学生,其实也一直过了很长时间都没明白这个问题,这说明吧不知道这个丢失更新问题是一个非常普遍的问题:)
b用信号量以及 *** 作之前再次验证的方法解决
最开始的时候,测试发现了这样一个问题,要求解决,我把 *** 作系统的教科书搬来,对照着写了一个信号量semaphore类[那时候还是jdk 142,jdk里面没有concurrent包],花了好长时间测试这个semaphore的实现是正确的[重复发明轮子的血泪史],
然后用来控制这个 *** 作,每次 *** 作前获取信号量,然后验证,再做真正的数据库 *** 作。。。相当于在应用层每次都只做一件事。
c 再次理解
再后来,我看了Tom的这本9i和10g的书,书中提到前面的丢失更新过程,大概有点明白为什么这是个问题
8a7315603d51c12ef97a82729cdc4677png
但是其实我有个疑问,对于数据库中的记录而言,A做的修改本来就有可能被B覆盖的,为什么这会是一个丢失更新问题呢 正好项目里面又出现了类似的情况,我仔细观察了下,终于明白为什么这是个问题,以及为什么要使用对应的乐观锁悲观锁方案了。下面对此做详细说明
3 一个比较清楚的场景
下面这个假设的实际场景可以比较清楚的帮助我们理解这个问题:
假设当当网上用户下单买了本书,这时数据库中有条订单号为001的订单,其中有个status字段是’有效’,表示该订单是有效的;
后台管理人员查询到这条001的订单,并且看到状态是有效的
用户发现下单的时候下错了,于是撤销订单,假设运行这样一条SQL: update order_table set status = ‘取消’ where order_id = 001;
后台管理人员由于在b这步看到状态有效的,这时,虽然用户在c这步已经撤销了订单,可是管理人员并未刷新界面,看到的订单状态还是有效的,于是点击”发货”按钮,将该订单发到物流部门,同时运行类似如下SQL,将订单状态改成已发货:update order_table set status = ‘已发货’ where order_id = 001
如果当当的系统这样实现,显然不对了,肯定要挨骂了,明明已经取消了订单,为什么还会发货呢而且确实取消订单的 *** 作发生在发货 *** 作之前啊。 因为在这样的实现下,后台管理人员无论怎么做都有可能会出错,因为他打开系统看到有效的订单和他点发货之间肯定有个时间差,在这个时间差的时候总是存在用户取消订单的可能。
4 当时的详细解决方法。几年前当测试人员告诉我系统存在这个问题的时候,我的解决方法是这样的, 首先,先把 *** 作系统的教科书搬来,然后对照着了一个semaphore,然后反复测试各种情况证明写的是正确的; 然后,
1 获取一个信号量,保证每次只能有一个线程进入下面的步骤
2 检查数据库,看这条订单是否状态是有效的
a 如果有效则继续,进入发货步骤 b) 如果无效则返回,释放信号量,告诉用户状态已经发生改变
3 发货,释放信号量
看到这里,也许很多人要骂我蠢了,直接把SQL语句改成下面这样吧就可以了么 update order_table set status = ‘已发货’ where order_id = 001 and status = ‘有效’ 是的,的确是这样。虽然我当时的项目的情况比和这个稍微复杂一点,涉及到多张表格,不能直接这么做,但当时的确不知道这个更新丢失问题,也没想到合适的类似方式,于是就在应用层做了这么一个每次实际上只能有一个用户在做真正的更新这样一个方式来解决,这样做的结果是,在应用层单独做了类似这么一个锁的机制。我记得当时的项目毕业答辩的时候,老师问我同步的这个问题不直接用数据库的锁的方案来解决我当时胡乱回答了下,后来想起来,其实压根没理解老师的意思-_- 而且这样做有一个问题,假设在特殊情况下,这条订单被DBA直接修改了,没有经过应用,那么应用做这个 *** 作也会是错的,因为在2a到3之前的这段时间,有可能正好是DBA直接修改的时候。那么3做的 *** 作也是不对的。 而且,现实情况是在后来的几年开发过程中,我也的确在一些不同的项目代码中看到,其他很多人也在使用类似的代码解决测试人员告诉他们的这些同步问题-_-
5正确而简洁的解决方法
问题清楚了,也说明了我曾经使用的解决方案也是一个简洁直接的解决方案,纯粹是把简单问题复杂化,下面说说实际有效的解决方案; 就这个丢失更新问题,可以通过数据库的锁来实现,基本两种思路,一种是悲观锁,另外一种是乐观锁; 简单的说就是一种假定这样的问题是高概率的,最好一开始就锁住,免得更新老是失败;另外一种假定这样的问题是小概率的,最后一步做更新的时候再锁住,免得锁住时间太长影响其他人做有关 *** 作;
6 乐观锁的方法
这里先说web开发中常用的乐观锁的方法:
1很简单,就是使用前面所说的这样一条SQL,这其实是所谓使用”前镜像”的方式来保证需要更新的数据是符合要求的,
update order_table set status = ‘已发货’ where order_id = 001 and status = ‘有效’ Tom的书上举的例子是对所有列做更新,所以他的SQL大致如下 Update table set col1 = newcol1value, col2 = newcol2value… where col1 = oldcol1value and col2 = oldcol2value… 这个我觉得需要根据应用具体分析,如果需要判断所有的值,那就判断所有的值,如果只关心其中一个或部分值,那只需要取相关的值就好了,就比如这里的订单的状态
2使用版本列[比如时间戳
这个方法比较简单,也最常用,就是在数据库表格中加一列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的维护,可以选择让应用每次都维护这个值,或者是使用存储过程来包装更新的 *** 作,或者是使用触发器来更新相关的值。几种方法各有利弊,比如应用维护需要保证每段相关代码都正确的维护了这个值;存储过程有一定的开销,通常很多开发对写存储过程可能也不熟练;触发器是简单的实现,但是也是有开销的。具体使用哪种方法需要根据实际情况具体取舍。
3使用校验或Hash值
这种方法和前面的方法类似,无非是根据其他有实际意义的列来计算出一个虚拟的列,我个人觉得TOM在介绍这个纯粹是介绍了一种”奇技*巧”,反正我是在实际过程中不知道哪里会需要这样的解决方案,或许也是因为我知道的太少了吧:)
4使用Oracle 10g的ORA_ROWSCN
这个就是利用10g的一个ora_rowscn特性,可以对每行做精确追踪,不过这个要求在create table的时候就指定相关参数,表格如果创建了以后就不能用alter table来修改了,因为这依赖于物理的实际存储。 同样,我觉得这也可以归为”奇技*巧”一类; 具体如果有兴趣了解详情的话,可以参考Tom的书
我们一直都在努力坚持原创请不要一声不吭,就悄悄拿走。
我原创,你原创,我们的内容世界才会更加精彩!
所有原创内容版权均属TechTarget,欢迎大家转发分享。但未经授权,严禁任何媒体(平面媒体、网络媒体、自媒体等)以及微信公众号复制、转载、摘编或以其他方式进行使用。
微信公众号
TechTarget
官方微博
TechTarget中国
相关资源:oracle乐观锁和悲观锁详细教程_oracle的乐观锁-Oracle文档类资源
点击阅读全文
打开CSDN,阅读体验更佳
Oracle数据库悲观锁与乐观锁_diweikang的博客
注:对于悲观锁是针对并发的可能性比较大,而一般在我们的应用中用乐观锁足以。 Oracle的悲观锁需要利用一条现有的连接,分成两种方式,从SQL语句的区别来看,就是一种是for update,一种是for update nowait的形式。 1 执行select xxx
ORACLE悲观锁和乐观锁_hongwei3344661的博客
1、无论是选择悲观锁策略,还是乐观锁策略。如果一个对象被上了锁,那么该对象都会受这个锁的控制和影响。 2、选择悲观锁策略,还是乐观锁策略,这主要是由应用和业务需求来确定的。如果你的应用和业务经常会出现从我看到要修改的记录的
oracle 乐观锁和悲观锁详细教程
详细介绍了Oracle中乐观锁、悲观锁的原理及应用,并有实例
基于ORACLE的乐观锁实现原理
2019独角兽企业重金招聘Python工程师标准>>>
继续访问
Oracle之悲观锁和乐观锁_hys21的博客
根据保护的对象不同,Oracle数据库锁可以分为以下几大类:DML锁(data locks,数据锁),用于实现并发存取并保护数据的完整性;DDL锁(dictionary locks,字典锁),用于保护数据库对象的结构,如表、索引等的结构定义;内部锁和闩(internal locks
oracle乐观锁和悲观锁详细教程_oracle的乐观锁-Oracle文档类资源
内部包含oracle百度网盘下载链接以及密码。 ocidll 12版本全部 资源是从Oracle官方网站下载,已测试可用 白雪红叶JAVA学习技术栈梳理思维导图xmind 乐观锁行级锁 分布式锁 分区排队 一致性 一致性算法 paxos zab nwr raft gossip
Oracle创建悲观锁和乐观锁
为了得到最大的性能,一般数据库都有并发机制,不过带来的问题就是数据访问的冲突。为了解决这个问题,大多数数据库用的方法就是数据的锁定。 考虑下面的情况。如果我们先查询到数据,然后更新数据。这样会出现这样的情况。A线程查询的时候,B线程也在查询,当A线程准备更新的时候,B线程先获得 了更新锁,将这些行锁定了。A只能等待B更新完。当B线程更新完释放锁的时候,A获得锁,这时A会识别出字段已经
继续访问
Oracle并发控制中的乐观锁
数据库的管理员要分散他们的数据库,以便处理基于Web,B2B,电子商务的访问,快速的硬盘读写以及更多的资源或许只能解决一部分问题。疲乏的锁机制甚至会削弱拥有很好资源的应用性能。乐观锁可以大大改善具有较多事务处理的数据库载入性能,比如基于web的客户端访问。 悲观锁引发的问题: 大多数Oracle开发者已经非常熟悉悲观锁,即在对数据进行更新之前给数据加锁。使用熟悉的SELECTFOR UP
继续访问
oracle乐观锁悲观锁学习笔记(更新中)_EvaronZ的博客
首先解释下乐观锁和悲观锁的含义 乐观锁:乐观锁就是认为数据一般情况下不会造成冲突,所以在数据进行提交更新的时候,才会正式对数据的冲突与否进行检测,如果发现冲突了,则返回错误的信息。 悲观锁:悲观锁就是对数据的冲突采取一种悲观的
Oracle乐观锁和悲观锁_◣NSD◥的博客_oracle悲观锁
乐观锁对应于生活中乐观的人总是想着事情往好的方向发展,悲观锁对应于生活中悲观的人总是想着事情往坏的方向发展。这两种人各有优缺点,不能不以场景而定说一种人好于另外一种人。 悲观锁
Oracle乐观锁悲观锁
1乐观锁 当处理对象状态时为了防止冲突 例:一个下订单的状态status a更新status为1购买,b取得status为1,这时a要退货把status改为2 这时如果b还按1的状态去处理,发货了。就出错了。 正确的做法为: 当b发货时,为了处理并发脏读,需要先根据原status状态去更新status为3订单处理中 int res = update
继续访问
转 Oracle中乐观锁定的四种实现方式
<br />Oracle中乐观锁定的四种实现方式<br /> <br />转自 >
expbd导出来的用impbd导入。
和版本没有关系,导出库时用的oracle版本和导入时用的不同。小版本不同也有影响。
解决办法:使用相同的数据泵导入导出。
OracleDatabase,又名OracleRDBMS,或简称Oracle。是甲骨文公司的一款关系数据库管理系统。它是在数据库领域一直处于领先地位的产品。可以说Oracle数据库系统是目前世界上流行的关系数据库管理系统,系统可移植性好、使用方便、功能强,适用于各类大、中、小、微机环境。它是一种高效率、可靠性好的适应高吞吐量的数据库解决方案。
ORACLE数据库系统是美国ORACLE公司(甲骨文)提供的以分布式数据库为核心的一组软件产品,是目前最流行的客户/服务器(CLIENT/SERVER)或B/S体系结构的数据库之一。比如就是基于数据库的一种中间件。ORACLE数据库是目前世界上使用最为广泛的数据库管理系统,作为一个通用的数据库系统,它具有完整的数据管理功能;作为一个关系数据库,它是一个完备关系的产品;作为分布式数据库它实现了分布式处理功能。但它的所有知识,只要在一种机型上学习了ORACLE知识,便能在各种类型的机器上使用它。
Oracle数据库最新版本为OracleDatabase12c。Oracle数据库12c引入了一个新的多承租方架构,使用该架构可轻松部署和管理数据库云。此外,一些创新特性可最大限度地提高资源使用率和灵活性,如OracleMultitenant可快速整合多个数据库,而AutomaticData和HeatMap能以更高的密度压缩数据和对数据分层。这些独一无二的技术进步再加上在可用性、安全性和大数据支持方面的主要增强,使得Oracle数据库12c成为私有云和公有云部署的理想平台。
你的数据库版本是哪个,我在11g下执行没问题,在10g下执行会报错,原因我还在查,不过晚上要坐火车,只能等明天了。
10g下需要先安装OLAP:
>
需要在防火墙中打开Oracle数据库监听器使用的TCP端口(默认为1521)以允许连接。如果已经打开了端口但仍然无法连接,则需要检查数据库监听器是否在运行,并检查网络连接和配置是否正确。
oraclecount一直出不来数量的原因和优化方法有索引问题、数据库性能问题、数据库锁问题、数据库版本问题。
1、索引问题:如果查询条件中的字段没有建立索引,或者索引失效,可能会导致oraclecount查询速度变慢,甚至无法返回结果。此时,可以通过建立索引或者优化查询语句来解决问题。
2、数据库性能问题:如果数据库的性能较差,例如内存不足、CPU占用率过高等,也可能导致oraclecount查询缓慢或者无法返回结果。此时,可以通过优化数据库配置或者增加服务器硬件资源来提升数据库性能。
3、数据库锁问题:如果在查询时出现了锁表或者锁行的情况,也会导致oraclecount无法返回结果。此时,可以通过查看数据库锁的情况,或者优化并发访问控制来解决问题。
4、数据库版本问题:如果使用的Oracle数据库版本较老,可能存在一些已知的Bug或者性能问题,需要升级到较新的版本来解决问题。
以上就是关于 *** 作oracle数据时报乐观锁异常全部的内容,包括: *** 作oracle数据时报乐观锁异常、数据库管理系统数据泵不一致(数据泵客户机与数据库版本不兼容)、oracle 数据库语言报错 求改正!!!等相关内容解答,如果想了解更多相关内容,可以关注我们,你们的支持是我们更新的动力!
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)