ORACLE DDL锁介绍

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

      因此，DDL总会提交（即使提交不成功也会如此）。DDL一开始就提交，一定要知道这一点。它首先提交，因此如果必须回滚，它不会回滚你的事务。如果你执行了DDL，它会使你所执行的所有未执行的工作成为永久性的，即使DDL不成功也会如此。如果你需要执行DDL，但是不想让它提交你现有的事务，就可以使用一个自治事务（换言之，在执行DDL语句之后，会立即提交事务。这样的话，在执行DDL语句之前，如果执行了DML语句，也会被一并提交，并且不可回滚。）

     有3种类型的DDL锁：

     1.排他DDL锁（Exclusive DDL lock）：这会防止其他会话得到它们自己的DDL锁或TM（DML）锁。这说明，在DDL操作期间你可以查询一个表，但是无法以任何方式修改这个表。

     2.共享DDL锁（Share DDL lock）：这些锁会保护所引用对象的结构，使之不会被其他会话修改，但是允许修改数据。

     3.可中断解析锁（Breakable parse locks）：这些锁允许一个对象（如共享池中缓存的一个查询计划）向另外某个对象注册其依赖性。如果在被依赖的对象上执行DDL，Oracle会查看已经对该对象注册了依赖性的对象列表，并使这些对象无效。因此，这些锁是“可中断的”，它们不能防止DDL出现。

 

     大多数DDL都带有一个排他DDL锁。比如发出如下一条语句：Alter table t add new_column date。

      但是，现在有些DDL操作没有DDL锁也可以发生。例如，可以发出以下语句：create index t_idx on t(x) ONLINE;

      ONLINE关键字会改变具体建立索引的方法。Oracle并不是加一个排他DDL锁来防止数据修改，而只会试图得到表上的一个低级（mode 2）TM锁。这会有效地防止其他DDL发生，同时还允许DML正常进行。Oracle执行这一“壮举”的做法是，为DDL语句执行期间对表所做的修改维护一个记录，执行CREATE时再把这些修改应用至新的索引。这样能大大增加数据的可用性。

      另外一类DDL会获得共享DDL锁。在创建存储的编译对象（如过程和视图）时，会对依赖的对象加这种共享DDL锁。例如，如果执行以下语句：

      Create view MyView
      as
      select *
      from emp, dept
      where emp.deptno = dept.deptno;

      表EMP和DEPT上都会加共享DDL锁，而CREATE VIEW命令仍在处理。可以修改这些表的内容，但是不能修改它们的结构。

      最后一类DDL锁是可中断解析锁。你的会话解析一条语句时，对于该语句引用的每一个对象都会加一个解析锁。加这些锁的目的是：如果以某种方式删除或修改了一个被引用的对象，可以将共享池中已解析的缓存语句置为无效（刷新输出）。

      有一个意义非凡的视图可用于查看这个信息，即DBA_DDL_LOCKS视图。对此没有相应的V$视图。DBA_DDL_LOCKS视图建立在更神秘的X$表基础上，而且默认情况下，你的数据库上不会安装这个视图。可以运行[ORACLE_HOME]/rdbms/admin目录下的catblock.sql脚本来安装这个视图以及其他锁视图。必须作为用户SYS来执行这个脚本才能成功。一旦执行了这个脚本，可以对视图运行一个查询。查询语句如下：

    select session_id sid, owner, name, type,mode_held held, mode_requested request from dba_ddl_locks

 

 

     这个视图对开发人员很有用，发现测试或开发系统中某段代码无法编译时，将会挂起并最终超时。这说明，有人正在使用这段代码（实际上在运行这段代码），你可以使用这个视图来查看这个人是谁。对于GRANTS和对象的其他类型的DDL也是一样。例如，无法对正在运行的过程授予EXECUTE权限。可以使用同样的方法来发现潜在的阻塞者和等待者。