前言
o racle数据库事务由于并发执行的原因，会产生各种各样的问题。oracle为了处理这些不同的问题，设计了不同的事务隔离级别：read committed(默认）及serializable
相关文章 oracle数据库事务不同事务隔离级别与v$transaction flag列思考
测试目标
2种不同事务隔离级别的在并发事务访问的差异性
测试明细
小结
可见serializable事务隔离级别，虽然可以实现绝对的数据一致性，但是事务并发访问能力要差于read committed。原因见上，直接就报ora-08177:can't serializable acess for this transaction.要知道并发访问期间，难免会产生相同的sql语句同时更新同一条表记录或同一个表的相关记录资源
read committed虽然并发访问好于serializable，但是容易产生数据不一致性，特别是在并发事务同时更新表的相同记录资源时，引起丢失更新。如果为了在事务期间不会导致丢失更新,update之前，一定先要select for update，如果select for update无法加锁，如果无法加锁，表明其它事务已经对于锁定的表记录资源正在更新。业务处理逻辑可以设定锁超时或者定制程序然后异常进行特定的处理。
事务隔离级别全是针对并发事务访问，起码2个事务以上。 serializable事务隔离级别适用的业务场景
数据库update语句更新的表记录数很少（注：因为更新的表记录越多，产生锁冲突的可能越大，则事务并发就会减少）
并发事务同时更新表的相同记录的可能性很小（注：如果更新相关表记录的并发事务越多，产生锁冲突可能越大，又会报ora-08177:can't serializable acess for this transaction,这样就会影响事务的并发访问）
长时间运行的事务，其中包含的SQL语句主要是只读select语句（注：select语句引起锁冲突的可能性很小，这样并发访问就可以保障）
所以说serializable事务隔离级别并不适用于高并发的事务访问环境 serializable事务隔离级别ora-08177处理方法
commit提交当前事务已经操作的部分操作的结果
rollback 回滚当前事务到一个保存点savepoint（不至于完全白作了）
rollback回滚整个当前事务
当然采用上述哪种处理方法，取决于你的于业务场景。每种业务场景对于数据的一致性要求不一样，有的是强一致性，有的是弱一致性,有的是最终一致性。大家可以根据不同的一致性需求选用合适的处理方法
培训课件
（收费20元）
联系方式
