Oracle事务在管理中的问题有哪些？

我们大家都知道如果一个Oracle事务里包含N多个相关的操作语句，而在此时实际操作中已对其中的几个进行了执行，也可以同时执行某个语句，那么我们就不能简单的认为前面几个执行的操作语句也还没发生。

这是要看Oracle事务的隔离级别的，但是不管事务隔离级别是几级，语句级别上可以认为是序列执行的。

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

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

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

Oracle死锁是怎么样产生的？

由于oracle控制并发是使用的锁机制，也因此即会产生死锁问题。oracle在执行一个语句时，会根据语句的含义，同时根据所处的事务隔离级别，解析出需要加什么样的锁，什么时候释放。而隔离级别越高，对锁资源占用越大。现在考虑这样的情形，oracle同时处理两个Oracle事务A,B。

A发过来几条语句，导致ORACLE加了几把锁没有释放，B发过来几条语句，导致ORACLE加了另外几把锁没有释放，现在，A又发过来一个语句，此语句要求ORACLE加的一些锁中，有几个锁已经被B事务占用，那么A等待，而B又发过来一条语句，此语句要求ORACLE加的锁，在A手中。于是死锁出现。

而隔离级别越高，死锁的可能性越大。可以分析出来，死锁的根本原因在于，Oracle事务包含的语句是分条发给oracle的，oracle不能够在事务开始时刻就解析出全部执行过程需要什么锁，什么时候释放，无法统一安排。

死锁问题归咎由谁呢？我这么理解：如果没有事务概念，oracle在语句级上控制并发，完全不会出现死锁问题。因为在解析语句时，oracle已经知道要加多少把锁，它会看目前这些锁如果能全部获得就执行，否则就等待。

可是实际应用怎么能没有事务的概念呢？我同意完全可以出现新的sql语法，可以把原来的多条sql语句的含义在一个语句中定义完毕，长短不是问题，牺牲一定的语法简洁度也不是问题;然而最关键的是往往我们是在一个业务处理逻辑中，多个数据库操作之间掺杂了其他非数据库操作，而又想获取这些数据库操作作为一个整体的ACID。

因此事务概念必须存在。既然如此，或许我们真得可以把一个Oracle事务可能包含的语句在事务开始时就交给oracle，尽管这样一来，有可能就包含了实际通过业务逻辑判断不会执行的语句，导致oracle浪费锁，降低并发处理能力。

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

尽管如此，在JAVA应用端使用同步要灵活很多，而不必限制在表锁行锁，你甚至可以建一个森林结构的信号量数据来控制同步。

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

【编辑推荐】