以下的文章主要介绍的实施Oracle事务管理的相关问题的总结，前两天在相关网站看见实施Oracle事务管理的相关问题的资料，觉得挺好，就拿出来供大家分享。实施Oracle事务管理的相关问题。
该SQL语句的操作过程中认为此数据状态是保持不变的。当此操作执行结束时刻，才产生语句级数据状态影响。就是说，可能该语句同时更新了两行，但都用了同一个主键，则此时会导致违反***性约定而消除整个语句的影响，如果成功执行，但未必就在Oracle事务级别上影响数据状态，就是说如果所在Oracle事务回滚，此影响仍然被消除，不过正如前面所说，一个语句成功执行后，就可能影响其他语句所面对的数据状态。51CTO数据库频道向您推荐《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已经知道要加多少把锁，它会看目前这些锁如果能全部获得就执行，否则就等待。可是实际应用怎么能没有Oracle事务的概念呢？
我同意完全可以出现新的sql语法，可以把原来的多条sql语句的含义在一个语句中定义完毕，长短不是问题，牺牲一定的语法简洁度也不是问题;然而最关键的是往往我们是在一个业务处理逻辑中，多个数据库操作之间掺杂了其他非数据库操作，而又想获取这些数据库操作作为一个整体的ACID。
因此事务概念必须存在。既然如此，或许我们真得可以把一个Oracle事务可能包含的语句在事务开始时就交给Oracle，尽管这样一来，有可能就包含了实际通过业务逻辑判断不会执行的语句，导致Oracle浪费锁，降低并发处理能力。
我之前的文章曾经介绍过用Java实现同步控制，降低Oracle隔离级别，只利用Oracle的原子性支持。这样做的原因就在上文中基本提到了。我们在编写Java业务逻辑时，是知道我们需要在一串业务逻辑中操作多少次数据库的，也因此，能够在业务逻辑开始时就控制得到所有的锁再执行。
这样做确实能够降低Oracle压力，并消除死锁问题，然而这样做会导致同步压力集中到Java应用端，而且对研发人员要求也会提高。尽管如此，在Java应用端使用同步要灵活很多，而不必限制在表锁行锁，你甚至可以建一个森林结构的信号量数据来控制同步。
呵呵，反过来也可以理解隔离级别的问题，为什么要存在允许幻像读的隔离级别呢？隔离级别的存在是一种权衡，如果应用既不想自己控制并发，又想提高并发能力，则需要好好权衡一下吧！
【编辑推荐】
