導讀：當我們發出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的身份登錄數據庫。
上文中介紹到的Oracle中的DDL鎖使Oracle數據庫中的數據安全得到了保障，避免數據庫中數據的丟失或者被人亂改。
