如果插入的数据有规律，可利用for、loop循环插入，主要用于批量生成测试数据
begin
for i in 1 100 loop
insert into test(xh,mc) values(i||'','测试');
end loop;
end ;。
2、采用insert into selct from 语句来一次性插入一个集合,这种主要依据于要插入的数据源已经存储于数据库对象中,或者利用dual虚表来构造数据，经过加工后写入一个集合。
insert into test (xh,mx) select '123','测试' from dual;
3、采用plsql等工具、或者oracle的imp、impdp命令来导入,这种主要用数据库与数据库之间的大批量数据导入，导入的数据格式为plsql的pde、oracle的dmp等。dmp文件可使用
table_exists_action参数控制导入动作:replace替换原表,truncate清除原表数据再导入，append增量导入数据，当然impdp数据泵的导入要依赖于directory路径。
impdp 用户名/密码 dumpfile=123dmp logfile=123log directory=imp_dir tables=test table_exists_action=append
4、使用excel文件直接拷贝。这种主要用于要写入的数据已是excel文件或者行列分明的其它格式文件，每一列的值和表结构相对应，可直接打开表的行级锁，把数据拷贝进入。
打开行级锁方法：
select t,rowid from 表名 t where 1=2;
select from 表名 where 1=2 for update;
直接把excel数据拷贝到表里户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 />转自 >题主是否想询问“oracledelete和update同时发生怎么办”？解决方法如下：
1、尽量避免在事务中同时使用DELETE和UPDATE语句，可以考虑分开执行这两种 *** 作。
2、在使用DELETE和UPDATE语句时，尽量不要对同一张表进行 *** 作，或者在 *** 作同一张表时，使用不同的条件和限定语句，避免多个 *** 作同时修改同一行数据。
3、在使用DELETE和UPDATE语句时，可以使用数据库锁定机制来避免事务冲突问题。例如，可以使用行级锁或表级锁来控制并发 *** 作，从而避免DELETE和UPDATE语句同时发生。数据库是一个多用户使用的共享资源。当多个用户并发地存取数据时，在数据库中就会产生多个事务同时存取同一数据的情况。若对并发 *** 作不加控制就可能会读取和存储不正确的数据，破坏数据库的一致性。
加锁是实现数据库并发控制的一个非常重要的技术。当事务在对某个数据对象进行 *** 作前，先向系统发出请求，对其加锁。加锁后事务就对该数据对象有了一定的控制，在该事务释放锁之前，其他的事务不能对此数据对象进行更新 *** 作。
在数据库中有两种基本的锁类型：排它锁（Exclusive Locks，即X锁）和共享锁（Share Locks，即S锁）。当数据对象被加上排它锁时，其他的事务不能对它读取和修改。加了共享锁的数据对象可以被其他事务读取，但不能修改。数据库利用这两种基本的锁类型来对数据库的事务进行并发控制。
根据保护的对象不同，Oracle数据库锁可以分为以下几大类：
DML锁（data locks，数据锁），用于保护数据的完整性；
DDL锁（dictionary locks，字典锁），用于保护数据库对象的结构，如表、索引等的结构定义；
内部锁和闩（internal locks and latches），保护数据库的内部结构，应用于SGA；
在我们实际应用开发中涉及较多的是DML锁，其他两种的话DBA会更加关心点；
DML锁的目的在于保证并发情况下的数据完整性，主要包括TM锁和TX锁，其中TM锁称为表级锁，TX锁称为事务锁或行级锁。
当Oracle执行DML语句时，系统自动在所要 *** 作的表上申请TM类型的锁。当TM锁获得后，系统再自动申请TX类型的锁，并将实际锁定的数据行的锁标志位进行置位。这样在事务加锁前检查TX锁相容性时就不用再逐行检查锁标志，而只需检查TM锁模式的相容性即可，大大提高了系统的效率。TM锁包括了SS、SX、S、X等多种模式，在数据库中用0－6来表示。不同的SQL *** 作产生不同类型的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 TABLE、DROP INDEX、
TRUNCATE TABLE、LOCK EXCLUSIVE
在数据行上只有X锁（排他锁）。在 Oracle数据库中，当一个事务首次发起一个DML语句时就获得一个TX锁，该锁保持到事务被提交或回滚。当两个或多个会话在表的同一条记录上执行 DML语句时，第一个会话在该条记录上加锁，其他的会话处于等待状态。当第一个会话提交后，TX锁被释放，其他会话才可以加锁。
在大概了解oracle的锁机制之后，我们来解决几个基本的问题：
1UPDATE/DELETE *** 作会将RS锁定，直至 *** 作被COMMIT或者ROLLBACK；
若 *** 作未COMMIT之前其他session对同样的RS做变更 *** 作，则 *** 作会被hold，直至前session的UPDATE/DELETE *** 作被COMMIT；
2session内外SELECT的RS范围
前提：INSERT、UPDATE *** 作未COMMIT之前进行SELECT；
若在同一session内，SELECT出来的RS会包括之前INSERT、UPDATE影响的记录；
若不在同一session内，SELECT出来的RS不会包括未被COMMIT的记录；
3SELECT FOR UPDATE [OF cols] [NOWAIT/WAIT] [SKIP LOCKED]
OF cols：只锁定指定字段所在表的RS，而没有指定的表则不会锁定，只会在多表联合查询时出现；
NOWAIT：语句不会hold，而是直接返回错误ORA-00054: resource busy and acquire with NOWAIT specified；
WAIT N：语句被hold N秒，之后返回错误ORA-30006: resource busy; acquire with WAIT timeout expired；
SKIP LOCKED：不提示错误，而是直接返回no rows selected；
以上几个选项可以联合使用的，比较推荐的有：
SELECT FOR UPDATE NOWAIT：对同一RS执行该SQL时，直接返回错误；
SELECT FOR UPDATE NOWAIT SKIP LOCKED：对同一RS执行该SQL时，直接返回空行；
PS：当RS被LOCK住之后，只对同样请求LOCK的语句有效，对无需LOCK的SELECT语句并没有任何影响；
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）