在ITPUB上看到有人提出了這個問題。在Sqlserver或一些其他的資料庫中，DDL語句也是可以回滾的，那麼Oracle為什麼不能回滾DDL語句呢。

要說明這個問題，首先需要說明什麼是DDL語句。DDL語句是資料定義語句，包括各種資料物件的建立、修改和刪除，以及授權等操作。

在Oracle中DDL語句將轉化為修改資料字典表的DML語句。一個簡單的修改表的DDL語句，會導致Oracle在後臺通過遞迴SQL語句進行大量的查詢和修改的操作。

如果有興趣，可以通過SQL_TRACE根據一下DDL語句，檢查一下Oracle後臺實際執行了哪些操作。

在Oracle中，Oracle執行DDL前會發出一個COMMIT語句，然後執行DDL操作，最後再發出一個COMMIT操作。

前面提到了對於Oracle而言，DDL實際上是資料字典表的一系列的修改，也就是資料字典表的DML操作，那麼理論上講Oracle是完全有能力實現DDL語句的回滾的，那麼Oracle為什麼設計成現在的工作方式。要知道Oracle以靈活和強大的可定製性著稱，但是Oracle沒有給使用者任何回滾DDL的可能性，顯示是存在著十分充分的理由。

首先分析一下Oracle為什麼要在DDL語句之前和之後各執行一次COMMIT，其實道理很簡單，Oracle是為了將使用者的讀寫操作和資料字典的修改隔離開，使用者資料的讀寫不應該和資料字典的操作放在同一個事務中。

為了說明Oracle為什麼不回滾DDL語句，下面假設Oracle可以回滾DDL語句，看看這會給Oracle資料庫帶來什麼影響。

從現在開始，假設DDL並不會自動提交，而是事務中的一部分。

那麼DDL就要滿足READ COMMIT隔離機制，也就是說，使用者執行的DDL語句在提交前，其他使用者是無法看到的。比如A使用者執行CREATE TABLE T的語句，然後對T執行了一些DML。而這時其他會話是無法看到T表的。

那麼考慮這樣的情況，存在表T，包含兩個列，一個ID列，一個CREATED列。

A會話執行了ALTER TABLE T MODIFY CREATED DEFAULT SYSDATE NOT NULL，然後對T表進行了一些插入，但是沒有提交。

這時B會話嘗試插入T表，如果DDL語句不是事務的一部分，那麼B的插入和A會話的插入之間沒有衝突，但是現在情況不同，由於A執行了T表的修改，為CREATED列增加了預設值並設定為NOT NULL，而且這個修改B會話當前是看不到的，因為A並沒有提交修改。這時如果B會話的插入沒有提供CREATED列的值，則插入操作將被鎖定。對於B而言，表結構中CREATED列仍然是可空的，因此允許插入CREATED列為空的記錄，但是由於A已經設定T的CREATED列非空，且包含預設值，因此B的插入必須被鎖定，否則如果A和B全部提交，A會話會發現即使執行了DDL語句，T表中仍然存在CREATED為空的記錄。Oracle為了實現DDL可以回滾的功能，且實現多版本讀一致性，那麼就必須在DDL發生後，將修改的表鎖定，避免其他會話的訪問造成不一致。這會導致Oracle中出現鎖升級的情況，並且嚴重的影響Oracle的併發性，而且會大大增加死鎖產生的機率。

        也許有人奇怪SQLSERVER或一些其他的資料庫為什麼可以實現DDL語句的回滾。事實上，前面提到了Oracle也是有能力實現DDL回滾的，只是這會極大的影響Oracle的併發性。要知道，Oracle的鎖機制和多版本讀一致性使得Oracle的併發性在所有資料庫產品中首屈一指。顯然為了實現DDL的回滾而損失最值得稱道的併發性，Oracle認為得不償失。其他資料庫之所以可以實現，是因為這些資料庫的鎖機制本身就存在一定缺陷，比如大量的鎖會佔用系統的資源、讀寫操作互相阻塞、行級鎖可能自動升級為表級鎖。由於已經存在這些問題，所以實現DDL的回滾並不會在很大程度上使得併發性惡化，因為即使DDL不將行鎖升級為表鎖，可能其他的因素也會導致這種情況的發生。

源：http://space.itpub.net/?uid-4227-action-viewspace-itemid-662747