当我们发出DDL命令时，会自动在被处理的对象上添加DDL锁定，从而防止对象被其他用户所修改。当DDL命令结束以后，则释放DDL锁定。我们不能显式地请 求一个DDL锁定，只有当对象结构被修改或者被引用时，才会在对象上添加DDL锁定。比如创建或者编译存储过程时会对引用的对象添加DDL锁定。在创建视图 时，也会对引用的表添加DDL锁定等。
在执行DDL命令之前，Oracle会自动添加一个隐式提交命令，然后执行具体的DDL命令，在DDL命令执行结束之后，还会自动添加一个隐式提交命令。实际上， Oracle在执行DDL命令时，都会将其转换为对数据字典表的DML操作。比如我们发出创建表的DDL命令时，Oracle会将表的名称插入数据字典表tab$里，同时将 表里的列名以及列的类型插入col$表里等。因此，在DDL命令中需要添加隐式的提交命令，从而提交那些对数据字典表的DML操作。即使DDL命令失败，它也会 发出提交命令。
我们来看下面的例子，启动两个session，其中一个叫做sess #1，另一个叫做sess #2。在sess #1里发出如下的SQL语句：
SQL> insert into t values(1);
1 row created.
然后在sess #2里查询表T里的数据：
SQL> select * from t;
no rows selected
显然，由于sess #1还没有提交，因此sess #2里不能检索出sess #1所插入的记录。接下来，我们在sess #1里执行下面的语句：
SQL> create table t(c1 number);
create table t(c1 number)
*
ERROR at line 1:
ORA-00955: name is already used by an existing object
由于表T已经存在，因此创建表T的命令失败。这时我们再回到sess #2里查询表T：
SQL> select * from t;
ID
----------
1
很明显，我们并没有在sess #1里发出commit命令，但这时sess #1里所作的插入操作已经被提交了。这个commit就是通过create table这个DDL命令隐式发出 的，尽管create table命令已经失败了。
DDL锁定具有以下三种类型。
（1）排他的DDL锁定（Exclusive DDL Lock）
大部分的DDL操作都会在被操作的对象上添加排他的DDL锁定，从而防止在DDL命令执行期间，对象被其他用户所修改。当对象上添加了排他的DDL锁定以后， 该对象上不能再添加任何其他的DDL锁定。如果是对表进行DDL命令，则其他进程也不能修改表里的数据。
（2）共享的DDL锁定（Shared DDL Lock）
用来保护被DDL的对象不被其他用户进程所更新，但是允许其他进程在对象上添加共享的DDL锁定。如果是对表进行DDL命令，则其他进程可以同时修改表里的 数据。比如我们发出create view命令创建视图时，在视图的所引用的表（这种表也叫基表）上添加的就是共享的DDL命令。也就是说，在创建视图时，其他 用户不能修改基表的结构，但是可以更新基表里的数据。
（3）可打破的解析锁定（Breakable Parsed Lock）
在shared pool里缓存的SQL游标或者PL/SQL程序代码都会获得引用对象上的解析锁定。如果我们发出DDL命令修改了某个对象的结构时，该对象相关的、位于 shared pool里的解析锁定就被打破，从而导致引用了该对象的SQL游标或者PL/SQL程序代码全都失效。下次再次执行相同的SQL语句时，需要重新解析，这也 就是所谓的SQL语句的reload了。可打破的解析锁定不会阻止其他的DDL锁定，如果发生与解析锁定相冲突的DDL锁定，则解析锁定也会被打破。
我们主要通过dba_ddl_locks视图来监控DDL锁定，没有与DDL锁定相关的V$视图。如果没有发现dba_ddl_locks视图，则执行脚本 $ORACLE_HOME/rdbms/admin/catblock.sql来创建该视图，执行脚本时应该以用户sys的身份登录数据库。
查看本栏目更多精彩内容：http://www.bianceng.cnhttp://www.bianceng.cn/database/Oracle/
我们来做个试验，并从dba_ddl_locks视图里查看有关DDL锁定的情况。在该试验中，我们创建一个存储过程，如下所示：
SQL> create or replace procedure p_test is
2 ln_id number;
3 begin
4 dbms_lock.sleep(600);
5 end;
6 /
在该存储过程中，我们调用dbms_lock.sleep，dbms_lock.sleep能够让系统挂起，挂起的时间长度由传入参数决定，传入参数的单位是秒。在本例中，也就 是让系统挂起600秒。
然后，我们启动三个session，并检索每个session的SID号，如下所示：
SQL> select sid from v$mystat where rownum=1;
SID
----------
149
SQL> select sid from v$mystat where rownum=1;
SID
----------
151
SQL> select sid from v$mystat where rownum=1;
SID
----------
159
在149号session里我们执行存储过程p_test：
SQL> exec p_test;
这时149号session被挂起，挂起持续的时间为600秒。然后我们到151号session里执行下面的SQL语句，对p_test进行编译：
SQL> alter procedure p_test compile;
我们会发现151号session也被挂起了，因为这时149号session正在执行p_test，因此151号的编译p_test命令必须等待。
接下来，我们到159号session里执行下面的语句，删除p_test：
SQL> drop procedure p_test;
显然，由于151号session正在编译p_test，我们也无法删除p_test，因此159号session也被挂起了。
我们查询dba_ddl_locks视图，来了解这时DDL锁定的情况：
SQL> select session_id,type,mode_held,mode_requested from dba_ddl_locks
2 where session_id in(149,151,159) and owner='HR' and name='P_TEST';
SESSION_ID TYPE MODE_HELD MODE_REQUESTED
---------- --------------------- --------- --------------
159 Table/Procedure/Type Null None
159 Table/Procedure/Type None Exclusive
151 Table/Procedure/Type Exclusive None
149 Table/Procedure/Type Null None
从MODE_HELD列上可以看到，151号session尝试编译p_test，因此它获得了p_test上的排他的DDL锁定。而从MODE_REQUESTED列上可以看到，159号session尝 试删除p_test，因此也需要在p_test上添加排他的DDL锁定。但是这时p_test上已经存在DDL锁定了，于是159号session只好等待。