Oracle中的DDL锁

有色

　　当我们发出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锁定具有以下三种类型。 　　ž 排他的DDL锁定(Exclusive DDL Lock) 　　大部分的DDL操作都会在被操作的对象上添加排他的DDL锁定，从而防止在DDL命令执行期间，对象被其他用户所修改。当对象上添加了排他的DDL锁定以后，该对象上不能再添加任何其他的DDL锁定。如果是对表进行DDL命令，则其他进程也不能修改表里的数据。 　　ž 共享的DDL锁定(Shared DDL Lock) 　　用来保护被DDL的对象不被其他用户进程所更新，但是允许其他进程在对象上添加共享的DDL锁定。如果是对表进行DDL命令，则其他进程可以同时修改表里的数据。比如我们发出create view命令创建视图时，在视图的所引用的表(这种表也叫基表)上添加的就是共享的DDL命令。也就是说，在创建视图时，其他用户不能修改基表的结构，但是可以更新基表里的数据。 [1] [2] 　　ž 可打破的解析锁定(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的身份登录数据库。 　　我们来做个试验，并从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 wner='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只好等待。 上一页 [1] [2]