Oracle中的锁类型

DML锁（DML lock） ：
DML代表数据操纵语言（Data Manipulation Language） 。一般来讲，
这表示 SELECT、INSERT、UPDATE、MERGE 和 DELETE 语句。DML 锁机制允许并发执行数
据修改。例如，DML锁可能是特定数据行上的锁，或者是锁定表中所有行的表级锁。

1.TX事务锁
事务发起第一个修改时会得到 TX 锁（事务锁），而且会一直持有这个锁，直至事务执行提交（COMMIT）或回滚（ROLLBACK） 。TX锁用作一种排队机制，使得其他会话可以等待这个事务执行。事务中修改或通过SELECT FOR UPDATE选择的每一行都会“指向”该事务的一个相关TX锁。
Oracle并 没有一个传统的锁管理器，不会用锁管理器为系统中锁定的每一行维护一个长长的列表。不过，其他的许多数据库却是这样做的，因为对于这些数据库来说，锁是一 种稀有资源，需要对锁的使用进行监视。使用的锁越多，系统要管理的方面就越多，所以在这些系统中，如果使用了“太多的”锁就会有问题。


如果数据库中有一个传统的基于内存的锁管理器，在这样一个数据库中，对一行锁定的过程一般如下：
(1) 找到想锁定的那一行的地址。
(2) 在锁管理器中排队（锁管理器必须是串行化的，因为这是一个常见的内存中的结构）。
(3) 锁定列表。
(4) 搜索列表，查看别人是否已经锁定了这一行。
(5) 在列表中创建一个新的条目，表明你已经锁定了这一行。
(6) 对列表解锁。
既然已经锁定了这一行，接下来就可以修改它了。之后，在你提交修改时，必须继续这个过程，如下：
(7) 再次排队。
(8) 锁住锁的列表。
(9) 在这个列表中搜索，并释放所有的锁。
(10) 对列表解锁。

可以看到，得到的锁越多，这个操作所花的时间就越多，修改数据前和修改数据之后耗费的时间都会增加。Oracle 不是这样做的。Oracle中的锁定过程如下：
(1) 找到想锁定的那一行的地址。
(2) 到达那一行。
(3) 锁定这一行（如果这一行已经锁定，则等待锁住它的事务结束，除非使用了NOWAIT选项）

仅此而已。由于闩为数据的一个属性，Oracle不需要传统的锁管理器。事务只是找到数据[5]，如果数据还没有被锁定，则对其锁定。有意思的是，找到数据时，它可能看上去被锁住了，但实际上并非如此。在Oracle中对数据行锁定时，行指向事务ID的一个副本，事务ID存储在包含数据的块中，释放锁时，事务ID却会保留下来。这个事务ID是事务所独有的，表示了回滚段号、槽和序列号。事务ID留在包含数据行的块上，可以告诉其他会话：你“拥有”这个数据（并非块上的所有数据都是你的，只是你修改的那一行“归你所有”） 。另一个会话到来时，它会看到锁ID，由于锁ID表示一个事务，所以可以很快地查看持有这个锁的事务是否还是活动的。如果锁不活动，则允许会话访问这个数据。如果锁还是活动的，会话就会要求一旦释放锁就得到通知。因此，这就有了一个排队机制：请求锁的会话会排队，等待目前拥有锁的事务执行，然后得到数据。


2. TM (DML Enqueue)锁


TM锁（TM lock）用于确保在修改表的内容时，表的结构不会改变。例如，如果你已经更新了一个表，会得到这个表的一个 TM 锁。这会防止另一个用户在该表上执行 DROP 或 ALTER 命令。如果你有表的一个TM 锁，而另一位用户试图在这个表上执行DDL，他就会得到以下错误消息：
drop table dept
*
ERROR at line 1:
ORA-00054: resource busy and acquire with NOWAIT specified
尽管每个事务只能得到一个TX锁，但是TM 锁则不同，修改了多少个对象，就能得到多少个TM 锁。
系统中允许的 TM 锁总数可以由你来配置（有关细节请见
Oracle Database Reference手册中的DML_LOCKS 参数定义） 。实际上，这个数可能设置为0。但这并不是说你的数据库变成了一个只读数据库（没有锁） ，而是说不允许DDL。在非常专业的应用（如RAC实现）中，这一点就很有用，可以减少实例内可能发生的协调次数。通过使用 ALTER TABLE TABLENAME DISABLE TABLE LOCK命令，还可以逐对象地禁用TM 锁。这是一种快捷方法，可以使意外删除表的“难度更大”，因为在删除表之前，你必须重新启用表锁。还能用它来检测由于外键未加索引而导致的全表锁。

DDL锁
在 DDL 操作中会自动为对象加 DDL 锁（DDL Lock） ，从而保护这些对象不会被其他会话所修改。
例如，如果我执行一个DDL 操作ALTERTABLE T，表T上就会加一个排他DDL锁，以防止其他会话得到这个表的DDL 锁和TM 锁。 在DDL语句执行期间会一直持有DDL锁， 一旦操作执行就立即释放DDL锁。实际上， 通常会把DDL语句包装在隐式提交 （或提交/回滚对） 中来执行这些工作。

有3种类型的 DDL锁：
排他DDL锁 （Exclusive DDL lock） ： 这会防止其他会话得到它们自己的DDL锁或 TM （DML）锁。这说明，在DDL操作期间你可以查询一个表，但是无法以任何方式修改这个表。
共享DDL锁（Share DDL lock） ：这些锁会保护所引用对象的结构，使之不会被其他会话修改，但是允许修改数据。
可中断解析锁（Breakable parse locks） ：这些锁允许一个对象（如共享池中缓存的一个查询计划）向另外某个对象注册其依赖性。如果在被依赖的对象上执行DDL，Oracle会查看已经对该对象注册了依赖性的对象列表，并使这些对象无效。因此，这些锁是“可中断的”，它们不能防止DDL出现。
闩
闩（latch）是轻量级的串行化设备，用于协调对共享数据结构、对象和文件的多用户访问。
闩就是一种锁，设计为只保持极短的一段时间（例如，修改一个内存中数据结构所需的时间） 。闩用于保护某些内存结构，如数据库块缓冲区缓存或共享池中的库缓存。一般会在内部以一种“愿意等待”（willing to wait）模式请求闩。这说明，如果闩不可用，请求会话会睡眠很短的一段时间，并在以后再次尝试这个操作。还可以采用一种“立即” （immediate）模式请求其他闩，这与 SELECT FOR UPDATE NOWAIT的 思想很相似，说明这个进程会做其他事情（如获取另一个与之相当的空闲闩） ，而不只是坐而等待这个闩直到它可用。由于许多请求者可能会同时等待一个闩，你会 看到一些进程等待的时间比其他进程要长一些。闩的分配相当随机，这要看运气好坏了。闩释放后，紧接着不论哪个会话请求闩都会得到它。等待闩的会话不会排 队，只是一大堆会话在不断地重试。
注意闩的自旋。