oracle事务管理相关问题总结

核心提示：1.oracle对一条sql语句的执行是怎么管理并发和恢复控制的? 一条符合语法的sql语句，定义了对数据库的操作，oracle事务管理相关问题总结，此操作执行的时刻，对应了数据库的一个数据状态，为什么要存在允许幻像读的隔离级别呢?隔离级别的存在是一种权衡，如果应用既不想自己控制并发，可以这样理解这个状态：到此执行时刻

1.oracle对一条sql语句的执行是怎么管理并发和恢复控制的?

一条符合语法的sql语句，定义了对数据库的操作。此操作执行的时刻，对应了数据库的一个数据状态。可以这样理解这个状态：到此执行时刻为止，没有任何数据库语句级操作正在并发执行;就是说实际上正在并发执行的多个语句级操作可以假定在此语句操作之后执行。这里强调语句级操作，是指如果一个事务包含多个操作语句，在此时刻实际已经执行了其中几个，此时刻也正在执行某一个语句，那么不能简单地认为前面几个执行的操作语句也还没发生，这是要看事务的隔离级别的，但是不管事务隔离级别是几级，语句级别上可以认为是序列执行的。

该sql语句的操作过程中认为此数据状态是保持不变的。当此操作执行结束时刻，才产生语句级数据状态影响。就是说，可能该语句同时更新了两行，但都用了同一个主键，则此时会导致违反唯一性约定而消除整个语句的影响，如果成功执行，但未必就在事务级别上影响数据状态，就是说如果所在事务回滚，此影响仍然被消除，不过正如前面所说，一个语句成功执行后，就可能影响其他语句所面对的数据状态。

2.PL/SQL的执行是怎么管理并发和恢复控制的?

PL/SQL是在一个PL/SQL引擎中执行的。该引擎可以认为是oracle之外的单位。该引擎会解析PL/SQL，并不断发送SQL语句给ORACLE。所以和用JAVA程序通过JDBC在一个会话连接中发送多个SQL语句没有本质差别。也因此并发和恢复管理没有不同。

3.oracle死锁是怎么样产生的?

由于oracle控制并发是使用的锁机制，也因此即会产生死锁问题。oracle在执行一个语句时，会根据语句的含义，同时根据所处的事务隔离级别，解析出需要加什么样的锁，什么时候释放。而隔离级别越高，对锁资源占用越大。现在考虑这样的情形，oracle同时处理两个事务A,B。A发过来几条语句，导致ORACLE加了几把锁没有释放，B发过来几条语句，导致ORACLE加了另外几把锁没有释放，现在，A又发过来一个语句，此语句要求ORACLE加的一些锁中，有几个锁已经被B事务占用，那么A等待，而B又发过来一条语句，此语句要求ORACLE加的锁，在A手中。于是死锁出现。而隔离级别越高，死锁的可能性越大。可以分析出来，死锁的根本原因在于，事务包含的语句是分条发给oracle的，oracle不能够在事务开始时刻就解析出全部执行过程需要什么锁，什么时候释放，无法统一安排。

死锁问题归咎由谁呢?我这么理解：如果没有事务概念，oracle在语句级上控制并发，完全不会出现死锁问题。因为在解析语句时，oracle已经知道要加多少把锁，它会看目前这些锁如果能全部获得就执行，否则就等待。可是实际应用怎么能没有事务的概念呢?我同意完全可以出现新的sql语法，可以把原来的多条sql语句的含义在一个语句中定义完毕，长短不是问题，牺牲一定的语法简洁度也不是问题;然而最关键的是往往我们是在一个业务处理逻辑中，多个数据库操作之间掺杂了其他非数据库操作，而又想获取这些数据库操作作为一个整体的ACID。因此事务概念必须存在。既然如此，或许我们真得可以把一个事务可能包含的语句在事务开始时就交给oracle，尽管这样一来，有可能就包含了实际通过业务逻辑判断不会执行的语句，导致oracle浪费锁，降低并发处理能力。

我之前的文章曾经介绍过用JAVA实现同步控制，降低ORACLE隔离级别，只利用ORACLE的原子性支持。这样做的原因就在上文中基本提到了。我们在编写JAVA业务逻辑时，是知道我们需要在一串业务逻辑中操作多少次数据库的，也因此，能够在业务逻辑开始时就控制得到所有的锁再执行。这样做确实能够降低oracle压力，并消除死锁问题，然而这样做会导致同步压力集中到JAVA应用端，而且对研发人员要求也会提高。尽管如此，在JAVA应用端使用同步要灵活很多，而不必限制在表锁行锁，你甚至可以建一个森林结构的信号量数据来控制同步。

呵呵，反过来也可以理解隔离级别的问题，为什么要存在允许幻像读的隔离级别呢?隔离级别的存在是一种权衡，如果应用既不想自己控制并发，又想提高并发能力，则需要好好权衡一下吧!