在很多方式上，数据定义语言的命令都与其它的事务没什么两样。关系型数据库需要这样的规则，以保证经过提交的数据定义语言永远不会被翻转，所有的数据定义语言都是自动提交的。你对此无法进行控制;COMMIT是所有数据定义语言命令中很重要的一部分。
Flashback Drop提供了一种方式让你能够撤销DROP TABLE 命令的影响，但是不能保证它会成功。这要根据执行了DROP命令之后数据库中进行的其它活动。你可以使用各种回闪查询命令来翻转数据治理语言命令，但是，还要再一次强调的是，它是否成功取决于在这段时间内发生的其它活动。不可能回滚一个已经提交的事务，无论是数据治理员语言还是数据定义语言。ACID测试不答应这样。回闪技术依靠于构建另一个可以翻转最初事务影响的事务，但是这个新的事务有可能会失败，因为其它的，相反的已经被提交的修改。
回闪删除
意外删除了一个表是非常有可能发生的。不仅仅是你有可能因为输入错误而删除了错误的表;也有可能是正确的表，但是你连接了错误的计划，或者是登录到错误的环境中去。你可以减少这种可能性，通过设置你的SQL*Plus提示，例如:
| SQL> set sqlprompt "_user'@'_connect_identifier> " SYSTEM@ocp10g> |
贴士:要让所有的SQL*Plus会话都自动设置你的提示符，在glogin.sql文件中添加上述命令，在ORACLE_HOME/sqlplus /admin目录里。
回闪删除可以让你恢复前面一个被删除的表(但是不是截取表)，就似乎它被删除之前。所有的索引都会被恢复，还有所有的触发器和许可。Unique，主键，还有非空约束也都会恢复，但是外键约束无法恢复了。
测验:回闪删除只能应用于表上，但是所有相关的对象也都会被恢复，除了外键约束。
回闪删除的实现
在Oracle数据库的早期版本中，当一个表被删除了，所有的参考都从数据字典中删除。假如有可能看到原来的DROP TABLE命令的源代码的话，你可以看到它实际上是一系列对定义了表和它的空间使用情况的系统计划中各种表的DELETE命令，后面跟着一个COMMIT。这实际上没有从硬盘中删除数据，但是删除表所用的空间被标志为没有使用，因此可以获得重用。即使是表所在的块还在，也没有可能取回它们了，因为数据字典已经没有对属于这个被删除的表的任何块有任何记录，惟一恢复被删除表的方法就是做一个时间点恢复，重新存储删除之前某个时间点的数据库版本，这个版本中数据字典中仍然保留表的信息。
在发布的10g Oracle数据库中，DROP TABLE命令的实现被完全改变了。表再也不是删除了，它们是被改名了。
在图29-1中，你可以看到这个表，OLD_NAME，占据的空间范围是64KB，从文件6的第17个块开始。在修改名字为NEW_NAME之后，存储空间还是如此;因此，表是一样的。查看DBA_OBJECTS视图，你可以看到表的对象号没有发生改变。10g版本中关于DROP TABLE命令的实现在内部映射到了RENAME命令，它会对标和所有相关的索引、触发器和约束产生影响，除了外键约束，它已经被删除了。外键约束实际上必须要删除。假如它们保留了的话，即使是换了一个名字，在没有被删除的父表上的数据治理语言就会被已经删除的表的目录所约束，这是荒谬的。
表上的许可没有名字，所以它们不能被改名。但是即使是当你给对象指定了某个名字的许可权限，后台存储的对象的许可参考仍然是靠着数字。因为对象号没有被RENAME操作修改，许可也就失效了。
评论加载中…
 |