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

這個問題來自：http://www.itpub.net/thread-1300088-1-5.html

?

?

要說明這個問題，首先需要說明什么是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不將行鎖升級為表鎖，可能其他的因素也會導致這種情況的發生。

?

總結

以上是生活随笔為你收集整理的DDL语句为什么不能回滚的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。