Oracle事务和锁机制

 

事务

1. 说明

　　一组SQL,一个逻辑工作单位，执行时整体修改或者整体回退。

2.事务相关概念

　　1）事务的提交和回滚：COMMIT/ROLLBACK

　　2）事务的开始和结束

　　　　开始事务：连接到数据库，执行DML、DCL、DDL语句

　　　　结束事务： 1. 执行DDL(例如CREATE TABLE),DCL(例如GRANT),系统自动执行COMMIT语句

　　　　　　　　　 2. 执行COMMIT/ROLLBACK

　　　　　　　　　 3. 退出/断开数据库的连接自动执行COMMIT语句

　　　　　　　　　 4. 进程意外终止，事务自动rollback

　　　　　　　　　 5. 事务COMMIT时会生成一个唯一的系统变化号（SCN）保存到事务表

　　3）保存点（savepoint）： 可以在事务的任何地方设置保存点，以便ROLLBACK

　　4）事务的四个特性ACID :

　　　　1. Atomicity（原子性）: 事务中sql语句不可分割，要么都做，要么都不做

　　　　2. Consistency(一致性) ： 指事务操作前后，数据库中数据是一致的，数据满足业务规则约束（例如账户金额的转出和转入），与原子性对应。

　　　　3. Isolation（隔离性）：多个并发事务可以独立运行，而不能相互干扰，一个事务修改数据未提交前，其他事务看不到它所做的更改。

　　　　4. Durability（持久性）：事务提交后，数据的修改是永久的。

　　5） 死锁：当两个事务相互等待对方释放资源时，就会形成死锁，下面章节详细分析

事务隔离级别

1 .两个事务并发访问数据库数据时可能存在的问题

　　1. 幻想读：

　　　　事务T1读取一条指定where条件的语句，返回结果集。此时事务T2插入一行新记录并commit，恰好满足T1的where条件。然后T1使用相同的条件再次查询，结果集中可以看到T2插入的记录，这条新纪录就是幻想。

　　2. 不可重复读取：

　　　　事务T1读取一行记录，紧接着事务T2修改了T1刚刚读取的记录并commit，然后T1再次查询，发现与第一次读取的记录不同，这称为不可重复读。 

　　3. 脏读：

　　　　事务T1更新了一行记录，还未提交所做的修改，这个T2读取了更新后的数据，然后T1执行回滚操作，取消刚才的修改，所以T2所读取的行就无效，也就是脏数据。

2.oracle事务隔离级别

oracle支持的隔离级别：（不支持脏读）

READ COMMITTED--不允许脏读，允许幻想读和不可重复读


SERIALIZABLE--以上三种都不允许

sql标准还支持READ UNCOMMITTED (三种都允许)和 REPEATABLE READ（不允许不可重复读和脏读，只允许幻想读）

以上区别在下面章节事务建立，隔离级别分析中说明

以上内容引用自：http://www.cnblogs.com/wishyouhappy/p/3698152.html

1.什么是事务，事务的特性是什么？

事务的任务便是使数据库从一种状态变换成为另一种状态，这不同于文件系统，它是数据库所特用的。它的特性有四个：TOM总结为ACID即
原子性atomicity:语句级原子性，过程级原子性，事务级原子性
一致性consistency:状态一致，同一事务中不会有两种状态
隔离性isolation:事务间是互相分离的互不影响(这里可能也有自治事务)
持久性durability:事务提交了，那么状态就是永久的

所谓死锁： 是指两个或两个以上的进程在执行过程中，因争夺资源而造成的一种互相等待的现象，若无外力作用，它们都将无法推进下去。此时称系统处于死锁状态或系统产生了死锁，这些永远在互相等待的进程称为死锁进程。 由于资源占用是互斥的，当某个进程提出申请资源后，使得有关进程在无外力协助下，永远分配不到必需的资源而无法继续运行，这就产生了一种特殊现象死锁。

关于数据库死锁的检查方法

一、数据库死锁的现象

程序在执行的过程中，点击确定或保存按钮，程序没有响应，也没有出现报错。

二、死锁的原理

当对于数据库某个表的某一列做更新或删除等操作，执行完毕后该条语句不提

交，另一条对于这一列数据做更新操作的语句在执行的时候就会处于等待状态，

此时的现象是这条语句一直在执行，但一直没有执行成功，也没有报错。

 

死锁的解决方法

一般情况下，只要将产生死锁的语句提交就可以了，但是在实际的执行过程中。用户可能不知道产生死锁的语句是哪一句。可以将程序关闭并重新启动就可以了。经常在Oracle的使用过程中碰到这个问题，所以也总结了一点解决方法。

  数据库是一个多用户使用的共享资源,比如一个用户表t_user,两个浏览器前面的人登录了同个一个账号，把电话号码改了。当多个用户并发地存取数据时，在数据库中就会产生多个事务同时存取同一数据的情况。若对并发操作不加控制就可能会读取和存储不正确的数据，破坏数据库的一致性(脏读，不可重复读，幻读等)，可能产生死锁。为了解决这个问题，加锁是一个非常重要的技术，对实现数据库并发控制是一个好的方案。简单说，当一个执行sql语句的事务想要操作表记录之前，先向数据库发出请求，对你访问的记录集加锁，在这个事务释放这个锁之前，其他事务不能对这些数据进行更新操作。

行级锁和表级锁是根据锁的粒度来区分的，行记录，表都是资源，锁是作用在这些资源上的。如果粒度比较小(比如行级锁)，可以增加系统的并发量但需要较大的系统开销，会影响到性能，出现死锁，，因为粒度小则操作的锁的数量会增加;如果作用在表上，粒度大，开销小，维护的锁少，不会出现死锁，但是并发是相当昂贵的，因为锁定了整个表就限制了其它事务对这个表中其他记录的访问。

锁包括行级锁、表级锁、悲观锁、乐观锁

行级锁:一种它锁，防止另外事务修改此行;在使用以下语句时，Oracle会自动应用行级锁：INSERT、UPDATE、DELETE、SELECT … FOR UPDATE [OF columns] [WAIT n | NOWAIT];SELECT … FOR UPDATE语句允许用户一次锁定多条记录进行更新.使用commit或者rollback释放锁。 特点:开锁大，加锁慢；会出现死锁；锁定粒度最小，发生锁冲突的概率最低，并发度也最高。适合于有大量按索引更新少量不同数据，同时又有并发查询的应用，如一些在线事务处理系统。

表级锁:5种

 共享锁(SHARE) - 锁定表，对记录只读不写，多个用户可以同时在同一个表上应用此锁，在表没有被任何DML操作时，多个事务都可加锁，但只有在仅一个事务加锁的情况下只有此事务才能对表更新；当表已经被更新或者指定要更新时（select for update），任何事务都不能加此锁了。

共享行排他(SHARE ROW EXCLUSIVE) – 比共享锁更多的限制，禁止使用共享锁及更高的锁，在表没有被任何DML操作时，只有一个事务可以加锁，可以更新，书上说别的事务可以使用select for update锁定选中的数据行，可是实验后没被验证。

   排他(EXCLUSIVE) – 限制最强的表锁，仅允许其他用户查询该表的行。禁止修改和锁定表

 行共享 (ROW SHARE) – 禁止排他锁定表，与行排他类似，区别是别的事务还可以在此表上加任何排他锁。（除排他（exclusive）外）

   行排他(ROW EXCLUSIVE) – 禁止使用排他锁和共享锁，其他事务依然可以并发地对相同数据表执行查询，插入，更新，删除操作，或对表内数据行加锁的操作，但不能有其他的排他锁（自身是可以的，没发现有什么用）

 

 悲观锁:

   Pessimistic Lock正如其名，它指的是对数据被外界（包括本系统当前的其他事务，以及来自外部系统的事务处理）修改持保守悲观态度，事务每次去操作数据的时候都假设有其他事务会修改需要访问的数据，所以在访问之前都要求上锁，行锁，表锁等，读锁，写锁等，都是在做操作之前先上锁，因此，在整个数据处理过程中，将数据处于锁定状态。

 一个典型的倚赖数据库的悲观锁调用： select * from account where name=”Erica” for update 这条sql 语句锁定了account 表中所有符合检索条件（name=”Erica”）的记录。 本次事务提交之前（事务提交时会释放事务过程中的锁），外界无法修改这些记录。

 

乐观锁:

   Optimistic Lock,和悲欢锁相反，事务每次去操作数据之前，都假设其他事务不会修改这些需要访问的数据 ，所以 在访问之前不要求上锁，只是在进行更新修改操作的时候判断一下在访问的期间有没有其他人修改数据 了。它适用于多读的应用类型，冲突真的发生比较少的时候就比较好，这样省去了开销的开销，可以提高吞吐量;但如果是真的经常要发生冲突的，那每次还要去判断进行retry,反倒降低的性能，这个时候悲欢锁比较好。数据库如果提供类似于write_condition机制的其实都是提供的乐观锁。

 

1.利润表t_profit中有一个 version字段，当前值为1；而总资产余额字段（balance）为$10000

       2.操作员A读出version=1,从总资产减除2000，10000-2000=8000.

       3.A还没操作结束，此时操作员B也读出version=1,总资产减除5000，10000-5000=5000.

       4.A操作完成，把version加1，修改为2，把总资产减2000后提交更新数据库，更新成功

       5.B操作了，也加version加1，修改为2，把总资产减5000后提交更新数据库，此时发现version已经为2了，如B修改后加1的version一样，不满足乐观锁策略:"提交的版本必有大于记录当前的版本才能执行"。因此B的操作请求被驳回，这样就避免了B就version=1的旧数据修改的结果覆盖了A操作的结果的可能。如没有乐观锁，那A减去2000后剩余8000，但B操作的时候是用10000-5000剩余5000的，如果B的提交成功，总资产余额就是5000，但实际情况应该是8000-5000=3000的。出现总资产表记录和实际支出不一致。

 

 

SQL> select * from t_book;
 
BOOKID BOOKNAME                                           PUBLISH
------ -------------------------------------------------- --------------------------------------------------
1      OracleTestForMine                                  ShenZhenPublish
2      JavaOKa                                            JiXieGongYePublish
 
SQL> savepoint a1;
 
Savepoint created
 
SQL> delete from t_book where bookid='2';
 
1 row deleted
 
SQL> select * from t_book;
 
BOOKID BOOKNAME                                           PUBLISH
------ -------------------------------------------------- --------------------------------------------------
1      OracleTestForMine                                  ShenZhenPublish
 
SQL> rollback to a1;
 
Rollback complete
 
SQL> select * from t_book;
 
BOOKID BOOKNAME                                           PUBLISH
------ -------------------------------------------------- --------------------------------------------------
1      OracleTestForMine                                  ShenZhenPublish
2      JavaOKa                                            JiXieGongYePublish