1.先给出DDL语句执行过程的伪代码描述BEGIN
commit;
DDL语句的解析，包括语法解析和语义解析;
BEGIN
执行DDL语句;
commit;
exception
when others then
rollback;
END;
END;
2.注意commit和rollback出现的地方
1）第一个commit，说明无论DDL语句执行成功与否，之前的所有操作均会被commit；
2）第二个commit，说明如果DDL执行成功，则没有“后悔药”可以吃，DDL语句即刻提交；
3）rollback，表示如果DDL执行失败，DDL本身的操作全部回退，但同样无法左右该DDL之前的那些被提交的操作行为。
3.通过一个scenario演示一下第一个commit的“可怕”之处
1）一位“神仙大人”手中有一张包含1万行记录的生产数据表t。
sec@ora10g> select count(*) from t;
COUNT(*)
----------
10000
2）“神仙大人”想要删除表中的一条记录，但是因为没有使用where子句，“误操作”删除了这张表的全部内容。这种误操作虽然可能性极小，不过这位“神仙大人”也有打瞌睡的时候。
sec@ora10g> delete from t;
10000 rows deleted.
3）这位“神仙大人”没有注意上面的1万行记录被删除的提示，鬼使神差的创建了一个序列s，目的是使用这个序列s完成他后续的维护任务。注意创建序列是一个DDL操作。
sec@ora10g> create sequence s;
Sequence created.
4）“神仙大人”在查询t表记录数后，猛然间意识到自己犯了一个重大的错误，一身冷汗！
sec@ora10g> select count(*) from t;
COUNT(*)
----------
0
5）“神仙大人”使用rollback回滚刚才的误操作，想找回一点点颜面。
sec@ora10g> rollback;
Rollback complete.
6）心神未定的“神仙大人”以为可以找回曾经失去的生产数据，可惜一切已经太迟、太迟了。
sec@ora10g> select count(*) from t;
COUNT(*)
----------
0
4.小结
这位“神仙大人”为什么无法回滚曾经的误操作？答案自明。
“神仙大人”经过这一次的洗礼，总结出以下几点：
1）对于SQL语句（DDL和DML）的执行过程需要了如指掌，避免一切死角；
2）在操作生产数据库的时候严谨“走神”，任何的误操作都是无法饶恕的；
3）在平时多加总结和积累；
4）在对生产数据库维护之前，如果有可能最好可以在测试数据库上先行操练一次；
5）细节决定价值，注意一切隐式行为的危害；
6）胆大心细，坐怀不乱（“神仙大人”的误操作也是有高级办法恢复的，不可一蹶不振）。
来自 “ ITPUB博客 ” ，链接：https://blog.itpub.net/22786751/viewspace-618401/
，如需转载，请注明出处，否则将追究法律责任。
