AnySQL.net

    原创工具AUL可以离开Oracle运行环境, 从数据文件中直接读取记录, 当你无法打开数据库(如丢失System表空间, System表空间损坏, 丢失其中一个数据文件, 数据文件时间点不一致, 表被Drop掉或Truncate掉)时, 可以考虑用它来读取剩余数据文件, 将数据恢复成文本文件或Dmp文件, 再装载或导入到新的数据库中. 因此可以被用于没有备份又无法打开数据库情况下的恢复.

    经过三年多的研究开发和完善, AUL的功能已经十分完美, 支持文本方式(第二版)及DMP方式(第三版),多种数据类型, 包括BLOB与CLOB(第四版)的恢复, 并在AUL第五版中成功支持压缩表. 支持最新的Oracle 11g版本数据库.

    到目前为止, 已经有来自十多个不同地区和国家的数十位客户选择了AUL作为终极恢复工具, 累计恢复的数据量已经超过1TB, 曾收到过1TB数据库的恢复请求, 更被真实地应用于一个2TB数据库的恢复实例中, 以最快的响应速度和最快的恢复速度(最短的案例是一个半小时, 从接到请求到将数据库恢复成文本文件)满足客户的要求.

    强烈建议大家做好数据库的备份工作, 欢迎大家在不知道如何备份或在恢复时遇到不明不清楚的问题时向我咨询.

    AUL工具可用于没有备份情况下的Oracle数据恢复, 提供服务的方式有多种, 顺便和用Oracle DUL提供恢复的方式比较了一下.

    1, 现场服务. 如果我们相距很近, 如在同一个城市, 或一两小时路程, 并且刚好是休息时间, 则可以提供现场服务. 比如在上海就提供过现场数据恢复服务, 缺点时受时间和地域限制. Oracle DUL恢复者也同样面临这样的问题.

    2, 上传下载. 如果我们相距不近, 并且数据库比较小, 则可以用这种方式, 现在Internet的速度也还可以了. 早期都只提供这种工作模式, 缺点是数据的安全性会被受到质凝, 如果数据文件有几个GB大小的话, 上传下载就不是那么快了, 从而导致了整个恢复的时间较长. Oracle DUL恢复者大都想采用这种方法.

    3, 远程登录. 在数据文件比较大时, 请允许我远程连接(VPN或Internet直连), 一般用这种方式. 省去了上传下载的时间, 也化解了地域的限制, 但很多人却提供不了这种方式, 因为他们用的不是原创的工具. 主要存在的问题是, 有时远程登录的环境比较难以配置, 并且还存在一个信任问题, 虽然我已经以这种方式提供了多次恢复, 但每次都要被客户问及信任问题. 但Oracle DUL的话, 是不会提供这种方法的, 不愿将软件放到你的服务器上.

    4, 自行恢复. 可以下载AUL软件, 并根据网上的文档学习如何恢复, 只要购买许可证后, 就可以在自我学习或我的指导下进行恢复, 保证了数据的安全性, 也不需要远程连接, 也不需要上传下载, 是比较理想的模式. 缺点是客户必须自已学会如何恢复, 技术要求较高, 同样很多人也提供不了这种模式, 国外的需求都使用这种方式. 人家更不会给Oracle DUL给你自行恢复了.

    AUL可以提供比Oracle DUL更灵活的恢复方式, 如果人家(不是原厂)不能提供第三第四种方式, 多半是用盗版Oracle DUL在恢复, 因为要将软件传到客户的机器上, 这是盗版Oracle DUL恢复提供者不愿意做的. 很多人改写了DUL或其它软件的界面(汉化原理), 冒充自己开发软件的, 也不愿意提供第三种, 第四种服务方式. 有些人虽号称是自已原创的工具, 但死活就是不肯放出个试用版本来.

    本站点上没有客户列表, 不是因为没有客户的原因, 是因为谁遇到了这种问题, 都希望能保密, 当作没有发生过. 因此在写之前都征求客户同意, 结果就没有写出来了.

    AUL的数据恢复主要关注于数据本身, 象存贮过程之类的代码AUL虽不自动整理, 但它们也不过是存放在系统表空间中的数据, 还是可以恢复的. 原理是将系统表的数据导出来, 再导入到新的库中, 然后自已 写SQL语句来进行查询, 以生成重建存贮过程的代码.

    先恢复几张系统表的数据.

unload table sys.user$ to sys_user.txt;
unload table sys.obj$ to sys_obj.txt;
set field_tag \x07
set record_tag \x06
unload table sys.source$ to sys_source.txt;

    调用建表角本, 创建表.

@USER$_syntax.sql
@SOURCE$_syntax.sql;
@OBJ$_syntax.sql

    运行sqlldr将数据导入到新的库, 注意不要将这些数据导入到SYS用户下.

sqlldr test/test crontrol=USER$_sqlldr.ctl
sqlldr test/test crontrol=OBJ$_sqlldr.ctl
sqlldr test/test crontrol=SOURCE$_sqlldr.ctl

    再写个SQL就可以很方便地获得某个用户下所有存贮过程或某个存贮过程的源代码了.

    AUL的数据恢复主要关注于数据本身, 象索引结构之类的信息AUL虽不自动整理, 但它们也不过是存放在系统表空间中的数据, 还是可以恢复的. 原理是将系统表的数据导出来, 再导入到新的库中, 然后自已 写SQL语句来进行查询, 列出表上的索引信息.

    除了SYS.USER$和SYS.OBJ$外, 我们还要导出下面几个系统表的数据.

unload table sys.ind$ to sys_ind.txt;
unload table sys.icol$ to sys_icol.txt;
unload table sys.col$ to sys_col.txt;

    调用建表角本, 创建表.

@IND$_syntax.sql
@ICOL$_syntax.sql
@COL$_syntax.sql

    运行sqlldr将数据导入到新的库, 注意不要将这些数据导入到SYS用户下.

sqlldr test/test control=IND$_sqlldr.ctl
sqlldr test/test control=ICOL$_sqlldr.ctl
sqlldr test/test control=COL$_sqlldr.ctl

    再写个SQL就可以很方便地获得某个用户下所有索引的结构了, 下面这名SQL中没有分区唯一性索引一否, 并且一定要在9i以上的版本中使用, 因为用了SYS_CONNECT_BY_PATH函数.

    AUL的数据恢复主要关注于数据本身, 象触发器代码AUL虽不自动整理, 但它们也不过是存放在系统表空间中的数据, 还是可以恢复的. 原理是将系统表的数据导出来, 再导入到新的库中, 然后自已 写SQL语句来进行查询, 就可以获得重建触发器的角本了.

    需要导出下面几个系统表的数据.

unload table sys.USER$ to sys_user.txt;
unload table sys.OBJ$ to sys_obj.txt;
SET FIELD_TAG \x07
SET RECORD_TAG \x06
unload table sys.TRIGGER$ to sys_trigger.txt;

    调用建表角本, 创建表.

@USER$_syntax.sql
@OBJ$_syntax.sql
@TRIGGER$_syntax.sql

    运行sqlldr将数据导入到新的库, 注意不要将这些数据导入到SYS用户下.

sqlldr test/test control=USER$_sqlldr.ctl
sqlldr test/test control=OBJ$_sqlldr.ctl
sqlldr test/test control=TRIGGER$_sqlldr.ctl

    再写个SQL就可以很方便地获得某个用户下触发器的代码了.