在一个繁忙的OLTP数据库中，最重要的特性莫过于并发性和一致性的控制。它的实现主要是靠lock来实现的，通常意义的lock包括如下几种：
TM LOCK，这种lock在大多数情况是为了保证在某个表上发生DML操作的时候，很多DDL操作时不与许的，这种lock是加载在相关的对象上的（比如表或者索引），有通常如下5种模式：RS,RX,S,SRX,X；
DDL 的lock 也有两种，一种是排他模式的；而第二种是共享模式的,如在线重建索引。
TX LOCK这种lock是加载在具体的数据块上，所以这种类型的lock并不需要进行全局的统一规划和管理，对于这种事务lock，一般的会发生在bitmap index的更新，ITL不足等，或者某些异常的进程退出后，PMON进程没有及时回收这些资源，主要是更新块中的相关标记。
另外一种lock称为lacth,对这类对象的操作必须是顺序话的，如果一个shared pool中的对象被一个进程获得了library cache lock，该lacth是加载在对象的handle上的，而该latch是排它的，如果这个操作执行的时间很长，则一直会持有这个latch，之后，会产生一个pin住该对象的操作，再做之前，一定要获取该对象的library cache pin 的lacth，一些DDL语句（如在没有提前建立索引的情况下，增加主键约束）在执行的规程中就有这样的问题，此时一些查询语句由于表的属性发生了变化，那么ORACLE 需要重新解析执行计划，在这个过程中发现无法获得相关对象lacth，导致执行计划无法生成，造成了读阻塞。
oracle 一致性读和当前读是两个容易混淆的概念，一致性读是select 语句去根据发生点的SCN号，去回滚段中读取前映像，而执行alter session set isolation_level=serializable ，可以之后的语句都保持第一SCN的点上，这时候会发现第一次的SCN的一致性读很大，而最后的逻辑读变小，在这种模式下，data buffer 中保留一个数据库的多个前影像，所以后面的一致性读变少了，而当前读与连续发生的DML语句有过，如果两个DML语句有关联，一个提交之后，会将结果应用于后一个相关的提交。对于执行性的问题ORACLE 通常有两种方式来解决：
1.悲观锁定：select ....... for update no wait
2.乐观锁定：利用一定的where 条件保证数据的一致性。
来自 “ ITPUB博客 ” ，链接：https://blog.itpub.net/48620/viewspace-401598/ ，如需转载，请注明出处，否则将追究法律责任。
