hive DDL锁（一）

我们目前使用的hive 元数据存储在mysql中，最近在使用过程中发现，如果对同一个对象（表）并发的进行ddl操作（例如：drop partition或者add partition）时会出现冲突，有时候表现为ddl语句报错，更有圣着有的DDL语句返回成功，但是实际上没有执行成功。通过show extended table发现很多时候HDFS分区的目录都已经建好，说明并发操作过程中数据出现的覆盖现象，于是近期要实现对HIVE DDL语句的加锁。

为了实现hive DDL锁先学习一下oracle的DDL锁做参考，一下内容引自：http://develop.csai.cn/dbms/200809051032351062.htm

　当我们发出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命令。也就是说，在创建视图时，其他用户不能修改基表的结构，但是可以更新基表里的数据。

　　ž 可打破的解析锁定(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只好等待。