DDL为什么不能rollback？

转自 http://blog.csdn.net/dba_waterbin/article/details/8621367

在Oracle中DDL语句将转化为对数据字典表的DML语句；比如，一个简单的修改表的DDL语句，会导致Oracle在后台通过递归SQL语句进行大量的查询和修改的操作

--DDL伪代码

begin
  commit;
  DDL_statement;
  commit;
end;

为什么前后有2个commit？
       道理很简单，Oracle是为了将用户的读写操作和数据字典的修改隔离开，用户数据的读写不应该和数据字典的操作放在同一个事务中

 ㈠ 并发性
       
       下面用反证法证明之
       
       假设Oracle可以回滚DDL语句，也就是，DDL并不会自动提交，而是事务中的一部分
       那么DDL就要满足READ COMMIT隔离机制，也就是说，用户执行的DDL语句在提交前，其他用户是无法看到的
       比如A用户执行CREATE TABLE T的语句，然后对T执行了一些DML。而这时其他会话是无法看到T表的

Session A>create table t (id number);--A没有commit！

Table created.

Session B>insert into t values (1);--此时T表对B是透明的

--这里应该会返回"ORA-00942: table or view does not exist"

Oracle为了实现DDL可以回滚的功能，且实现多版本读一致性，那么就必须在DDL发生后，将修改的表锁定,避免其他会话的访问造成不一致
       这会导致Oracle中出现锁升级的情况，并且严重的影响Oracle的并发性，而且会大大增加死锁产生的几率
       要知道，Oracle的锁机制和多版本读一致性使得Oracle的并发性在所有数据库产品中首屈一指
       显然为了实现DDL的回滚而损失最值得称道的并发性，Oracle认为得不偿失    
         
       
       ㈡ 成本论
       
       因为DDL操作在数据库里都被解析为一系列的DML操作，操作的对象都是如obj$,seg$等数据字典表，这些东西都存储在系统表空间  
       这个如果回滚的话，导致递归的操作，估计系统也就垮了而且性能会下降
       
       经济学上，有个"比较成本论"，举个例子：
       如果两个人都能制鞋和帽，其中一人在两种职业上都比另一个人强一些，不过制帽子时只强1/5或20%，而制鞋时则强1/3或33%
       那么这个较强的人专门制鞋，而那个较差的人则专门制帽，岂不是对双方都有利么？
       
       推及到Oracle上，业务的读写操作和数据字典的读写操作如能按上述个人之间的分工原理进行协同工作，也必将会使各方获得利益   
       
         
       OCP考题--007：

Q: 4 Evaluate the set of SQL statements:

CREATE TABLE dept
(deptno NUMBER(2),
dname VARCHAR2(14),
loc VARCHAR2(13));

ROLLBACK;

DESCRIBE DEPT

What is true about the set?

A. The DESCRIBE DEPT statement displays the structure of the DEPT table.
B. The ROLLBACK statement frees the storage space occupied by the DEPT table.
C. The DESCRIBE DEPT statement returns an error ORA-04043: object DEPT does not exist.
D. The DESCRIBE DEPT statement displays the structure of the DEPT table only if there is a COMMIT
statement introduced before the ROLLBACK statement.

Answer: A