为了得到最大的性能,一般数据库都有并发机制,不过带来的问题就是数据访问的冲突。为了解决这个问题,大多数数据库用的方法就是数据的锁定。
数据的锁定分为两种方法,第一种叫做悲观锁,第二种叫做乐观锁。什么叫悲观锁呢,悲观锁顾名思义,就是对数据的冲突采取一种悲观的态度,也就是说假设数据肯定会冲突,所以在数据开始读取的时候就把数据锁定住。而乐观锁就是认为数据一般情况下不会造成冲突,所以在数据进行提交更新的时候,才会正式对数据的冲突与否进行检测,如果发现冲突了,则让用户返回错误的信息,让用户决定如何去做。
先从悲观锁开始说。在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
也就是没有for update这种锁定数据的语句的话,就不会造成阻塞了。另外一种情况,就是当数据库数据被锁定的时候,也就是执行刚才for update那条sql以后,我们在另外一个session中执行for update nowait后又是什么样呢。比如如下的sql语句。 由于这条语句中是制定采用nowait方式来进行检索,所以当发现数据被别的session锁定中的时候,就会迅速返回ORA-00054错误,内容是资源正忙, 但指定以 NOWAIT 方式获取资源。所以在程序中我们可以采用nowait方式迅速判断当前数据是否被锁定中,如果锁定中的话,就要采取相应的业务措施进行处理。
select * from test where id = 10 for update nowait
那这里另外一个问题,就是当我们锁定住数据的时候,我们对数据进行更新和删除的话会是什么样呢。比如同样,我们让第一个Session锁定住id=10的那条数据,我们在第二个session中执行如下语句。
update test set value=2 where id = 10
这个时候我们发现update语句就好像select for update语句一样也停住卡在这里,当你第一个session放开锁定以后update才能正常运行。当你update运行后,数据又被你update语句锁定住了,这个时候只要你update后还没有commit,别的session照样不能对数据进行锁定更新等等。
总之,Oracle中的悲观锁就是利用Oracle的Connection对数据进行锁定。在Oracle中,用这种行级锁带来的性能损失是很小的,只是要注意程序逻辑,不要给你一不小心搞成死锁了就好。而且由于数据的及时锁定,在数据提交时候就不呼出现冲突,可以省去很多恼人的数据冲突处理。缺点就是你必须要始终有一条数据库连接,就是说在整个锁定到最后放开锁的过程中,你的数据库联接要始终保持住。与悲观锁相对的,我们有了乐观锁。乐观锁一开始也说了,就是一开始假设不会造成数据冲突,在最后提交的时候再进行数据冲突检测。在乐观锁中,我们有3种
常用的做法来实现。
[1]第一种就是在数据取得的时候把整个数据都copy到应用中,在进行提交的时候比对当前数据库中的数据和开始的时候更新前取得的数据。当发现两个数据一模一样以后,就表示没有冲突可以提交,否则则是并发冲突,需要去用业务逻辑进行解决。
[2]第二种乐观锁的做法就是采用版本戳,这个在Hibernate中得到了使用。采用版本戳的话,首先需要在你有乐观锁的数据库table上建立一个新的column,比如为number型,当你数据每更新一次的时候,版本数就会往上增加1。比如同样有2个session同样对某条数据进行操作。两者都取到当前的数据的版本号为1,当第一个session进行数据更新后,在提交的时候查看到当前数据的版本还为1,和自己一开始取到的版本相同。就正式提交,然后把版本号增加1,这个时候当前数据的版本为2。当第二个session也更新了数据提交的时候,发现数据库中版本为2,和一开始这个session取到的版本号不一致,就知道别人更新过此条数据,这个
时候再进行业务处理,比如整个Transaction都Rollback等等操作。在用版本戳的时候,可以在应用程序侧使用版本戳的验证,也可以在数据库侧采用Trigger(触发器)来进行验证。不过数据库的Trigger的性能开销还是比较的大,所以能在应用侧进行验证的话还是推荐不用Trigger。
[3]第三种做法和第二种做法有点类似,就是也新增一个Table的Column,不过这次这个column是采用timestamp型,存储数据最后更新的时间。在Oracle9i以后可以采用新的数据类型,也就是timestamp with time zone类型来做时间戳。这种Timestamp的数据精度在Oracle的时间类型中是最高的,精确到微秒(还没与到纳秒的级别),一般来说,加上数据库处理时间和人的思考动作时间,微秒级别是非常非常够了,其实只要精确到毫秒甚至秒都应该没有什么问题。和刚才的版本戳类似,也是在更新提交的时候检查当前数据库中数据的时间戳和自己更新前取到的时间戳进行对比,如果一致则OK,否则就是版本冲突。如果不想把代码写在程序中或者由于别的原因无法把代码写在现有的程序中,也可以把这个时间戳乐观锁逻辑写在Trigger或者存储过程中。
不知道这个是不是你需要的...参考资料:http://www.bianchengzhe.org/ziliao/sjk/oracle/3412.html
1、悲观锁,正如其名,它指的是对数据被外界(包括本系统当前的其他事务,以及来自外部系统的事务处理)修改持保守态度,因此,在整个数据处理过程中,将数据处于锁定状态。悲观锁的实现,往往依靠数据库提供的锁机制(也只有数据库层提供的锁机制才能真正保证数据访问的排他性,否则,即使在本系统中实现了加锁机制,也无法保证外部系
统不会修改数据)。
2、乐观锁( Optimistic Locking )
相对悲观锁而言,乐观锁机制采取了更加宽松的加锁机制。悲观锁大多数情况下依靠数据库的锁机制实现,以保证操作最大程度的独占性。但随之而来的就是数据库性能的大量开销,特别是对长事务而言,这样的开销往往无法承受。
而乐观锁机制在一定程度上解决了这个问题。乐观锁,大多是基于数据版本( Version )记录机制实现。何谓数据版本?即为数据增加一个版本标识,在基于数据库表的版本解决方案中,一般是通过为数据库表增加一个 “version” 字段来实现。读取出数据时,将此版本号一同读出,之后更新时,对此版本号加一。此时,将提交数据的版本数据与数据库表对应记录的当前版本信息进行比对,如果提交的数据版本号大于数据库表当前版本号,则予以更新,否则认为是过期数据。参考资料:http://www.cnblogs.com/illele/archive/2007/12/20/912062.html
分享到:
相关推荐
Oracle中的用户级(UL)锁就是一种悲观锁,它允许用户自定义锁机制,提供更细粒度的控制。 PL/SQL UL LOCK的实现通常涉及以下几个步骤: 1. **创建锁表**:首先,你需要创建一个表来存储锁定信息。这个表通常包含...
悲观锁和乐观锁是两种不同的并发控制策略。 - **悲观锁**:假设数据会发生冲突,因此在事务开始时即锁定数据,直到事务结束。这种方式虽然能有效避免冲突,但可能导致资源占用时间较长。 - **乐观锁**:假设数据...
在数据库系统中,为了保证数据的一致性和完整性,有多种并发控制策略,其中包括乐观锁和悲观锁。这两种锁机制主要用于解决事务在并发环境中的数据冲突问题。 乐观锁是一种假设事务在执行过程中不会发生冲突的策略。...
Oracle的并发控制机制,如行级锁、乐观锁、悲观锁等,可以避免数据冲突,保证数据的一致性。 5. **索引优化**:为了提高查询效率,我们可能需要为经常被查询的字段创建索引。Oracle支持B树索引、位图索引等多种类型...
- **乐观锁**:假设很少发生冲突,因此在提交事务时检查是否有冲突,如版本控制或时间戳。 - **悲观锁**:在访问数据时立即锁定,防止其他用户修改,适合高冲突环境。 4. **锁定级别**: - **多粒度锁定...
了解事务的ACID特性(原子性、一致性、隔离性和持久性),以及乐观锁、悲观锁和多版本并发控制(MVCC)机制,对理解并发控制至关重要。 八、备份与恢复 Oracle提供多种备份和恢复策略,如物理备份、逻辑备份、RMAN...
乐观锁在Oracle数据库并发控制中的应用 乐观锁是一种在数据库管理系统中实现并发控制的方法,它假设在多数情况下读多写少的情况,因此在读取数据时不会加锁,只有在更新数据时才会检查在此期间是否有其他事务修改了...
乐观锁和悲观锁是常见的并发控制策略,还有行级锁定和多版本并发控制(MVCC)机制。 7. **备份与恢复**:Oracle支持多种备份方式,如物理备份、逻辑备份、RMAN(恢复管理器)备份。了解如何进行数据库恢复,包括闪...
6. 多版本并发控制:支持乐观锁和悲观锁,确保在多用户环境中数据的一致性和完整性。 7. JTA(Java Transaction API)集成:支持全局事务管理,确保分布式事务的正确性。 8. 回滚和提交:提供Connection对象的...
4. 锁机制:了解和使用Oracle的锁定机制来处理并发事务,包括乐观锁定和悲观锁定。 5. 数据库触发器:编写触发器来自动执行任务,在数据变更前后提供业务逻辑自动化。 6. 索引优化:分析和创建索引以优化查询性能,...
11. **事务和并发控制**:讲解事务的基本概念(ACID属性),提交(COMMIT)、回滚(ROLLBACK)和保存点(SAVEPOINT),以及乐观锁和悲观锁在并发环境下的应用。 12. **数据库安全性**:用户权限的管理,角色(Role...
7. **事务和并发控制**:理解事务的概念,学习如何使用COMMIT、ROLLBACK和SAVEPOINT,以及了解锁定机制和乐观锁、悲观锁的区别。 8. **数据库设计**:学习关系数据库设计原则,如范式理论(1NF、2NF、3NF、BCNF),...
10. **事务和并发控制**:理解事务的概念,掌握COMMIT、ROLLBACK和SAVEPOINT操作,以及乐观锁和悲观锁的原理。 11. **存储过程和函数**:创建和调用自定义的PL/SQL程序单元,提升代码复用性和执行效率。 12. **...
- 锁机制:学习行级锁、表级锁以及乐观锁和悲观锁的区别。 7. **数据库设计**: - 正范化理论:学习第一至第五范式,理解如何设计规范化的数据库模式。 - 实体关系模型:理解和应用ER图进行数据库设计。 8. **...
8. **并发控制**:在多用户环境下,理解锁和并发控制机制(如乐观锁、悲观锁、行级锁定和多版本并发控制MVCC)对于防止数据不一致和死锁至关重要。 9. **异常处理**:在PL/SQL中,异常处理是通过异常块实现的,它...
2. **并发控制**:乐观锁和悲观锁机制,以及行级锁定和表级锁定。 3. **分区表**:通过将大表分成较小的部分来优化查询性能和管理大数据。 4. **索引逆序键**:用于提高查询性能,尤其在查询时涉及大量排序或分组的...
12. 锁与并发控制:理解行级锁、表级锁以及乐观锁和悲观锁的概念,学习如何处理并发问题。 以上只是Oracle SQL学习中的一部分关键知识点。通过深入学习和实践这些内容,你将能够更好地理解和操作Oracle数据库。这个...
- 锁和并发:了解乐观锁和悲观锁的概念,以及Oracle中的多版本并发控制(MVCC)。 8. **存储过程和函数**: - 创建和调用存储过程:编写和执行自定义的数据库操作集合。 - 用户定义函数:创建自己的函数,以便在...
避免死锁的最佳实践包括合理设计事务大小,避免长时间的事务,及时释放不需要的锁,以及使用乐观锁定代替悲观锁定。 22. Oracle中的备份和恢复策略有哪些? 备份和恢复策略包括全库备份、数据文件备份、控制文件...
6. **事务与并发控制**:掌握事务的ACID属性,以及乐观锁和悲观锁的概念,了解死锁和解决策略。 7. **备份与恢复**:学习如何进行数据库备份,以及如何在数据丢失或系统故障时进行恢复。 8. **性能调优**:通过SQL...