在AnySQL.net中搜索标签(Tags) 'AUL/MyDUL' 的结果:
Oracle DUL不行就用AUL
几天以前, 有个朋友告诉我某单位的Oracle数据库坏了, 需要恢复, 很想推荐人家用AUL的, 不过客户自已只信任Oracle的, 并且Oracle已经介入了. 于是我就笑着说, Oracle DUL不行时再来用AUL吧. 其实也只是随便说说而已, 没想到昨天再接到那朋友的电话, 说是Oracle DUL恢复遇到了问题, 客户有CLOB列中存放了很多中文, 用DUL恢复出来后, 这些字段值都成了乱码. 形成这个乱码原因当然是由于Oracle CLOB列的特殊性, 以及DUL作者不是中国人, 所以没有考虑到CLOB中的中文情况. 来咨询AUL是否可以处理这些乱码, 我欣然说可以. 客户马上联系我, 下载AUL, 在我的指导下很快就恢复了第一张表, CLOB中的中文内容没有大问题, 却有些小问题, 某些地方总是多了一些问号, 这个问题最好可以完美解决. 形成这个问题的原因是, AUL中只支持了GB2312字符集中的常用汉字以及中文符号, 现在大家都用支持更多中文字和中文符号的GBK字符集了, 因此有些不在GB2312字符集中的汉字或符号在转换时就成了问号, 这就是问号的来源....
AUL Sybase数据恢复工具
前段时间想着要发展其他数据库上面的AUL恢复软件, 前段时间联系了一个Sybase上的高手, 开发了AUL for Sybase, 现在提供的是测试版本, 我们也正在努力地完善它. 用Sybase的数据库朋友可以试试....
AUL也走品牌路线?
三年多前为了深入Oracle而选择研究数据块格式, 并在不经意之间写成了AUL恢复软件, 有些无心插柳柳成荫的味道. 当你将一门技术掌握到全国或全世界顶尖的水平时, 肯定可以用它来为人们排忧解难, 人们也会愿意为之支付相应的报酬. 这也算是做技术的一种动力吧, 首先是帮人排忧解难, 然后是得到回报, 其实做服务的真谛也不外是如此. 这三年下来, AUL也算一个小小的品牌了. 目前AUL还只有Oracle版本的, 为了要更好地为大家排忧解难, 要努务发展以下的几个平台. AUL for Oracle ASM AUL for Sybase AUL for SQLServer AUL for MySQL Innodb AUL成系列后, 是不是很好记啊? AUL等于AnySQL UnLoader的缩写. 其中Sybase和SQL...
选择AUL恢复数据的理由
某全球500强企业的数据库坏了, 都将AUL列为恢复的方案之一, 为什么? 1, 比Oracle的恢复服务便宜, 节约成本. 2, 比Oracle的恢复服务着更快的响应速度. 3, 和Oracle的恢复服务一样的优质, 并且合法. 4, 让更少的人知道数据库出现的问题. 有这些下由, 还不心动吗? 回头一看, 在AUL的支持和驱动下, 已经有500篇文章了. 曾经有一美国企业因为受不了Oracle的反应速度, 最终选择了AUL作为恢复解决方案, 在等了Oracle几天后, 联系了AUL, 只用了1.5小时, 就将数据恢复回来了. ...
不是好人, 这么无耻!
对有一件事情一直不能忘怀, 不得不重提旧事, 想起AUL/MyDUL以前被诽谤的事, 有个人在他自已的QQ群中使劲说他的MYjDUL有多了不起, 还不停地遇人就说AUL/MyDUL是抄jDUL的源代码的, 来中伤本人真正原创的软件. 那时因为忙于改进和完善软件, 因此没有空去理这件事, 经过了三年的发展, 数十次的恢复经历, 相当完善后. 才有空去了解这件事. 经过从多个网友了解来的信息, 充分信某网站宣称自主开发的MYjDUL其实只是AUL/MyDUL第一版的Java源代码而已, 结果还要说AUL是抄jDUL的, 有些人居然做这么丢脸的事. 因为那一版的程序框架是不成熟的, 没有什么正式的作用, 因此MYjDUL也只不过是一个吓人的名称而已, 没有真正实用的软件, 连个试用版本都没有呢. 很久以前我在网上放出过那份源代码, 几个月前正式放出那份源代码, 看他还怎么叫? 厚黑学中说做人可以脸皮厚一些, 但也不能厚到这种程度, 和那个打磨汉芯的长江学者有得一比了. 也不知道Oracle为什么不去查一下这种非法盗用DUL去恢复的情况. 强列建议Oracle也用我这种许可证方式, 需要用员工号去申请许可证, 这样就知道是那个内鬼放出去的了. 另外一个证据是他做不了我的第三第四种恢复方式....
AUL恢复Oracle视图代码?
AUL的数据恢复主要关注于数据本身, 象视图代码AUL虽不自动整理, 但它们也不过是存放在系统表空间中的数据, 还是可以恢复的. 原理是将系统表的数据导出来, 再导入到新的库中, 然后自已 写SQL语句来进行查询, 就可以获得重建视图的角本了. 需要导出下面几个系统表的数据. unload table sys.USER$ to sys_user.txt; unload table sys.OBJ$ to sys_obj.txt; unload table sys.COL$ to sys_col.txt; SET FIELD_TAG \x07 SET RECORD_TAG \x06 unload table sys.view$ to sys_view.txt;...
AUL恢复Oracle Sequence?
AUL的数据恢复主要关注于数据本身, 象Sequence的信息AUL虽不自动整理, 但它们也不过是存放在系统表空间中的数据, 还是可以恢复的. 原理是将系统表的数据导出来, 再导入到新的库中, 然后自已 写SQL语句来进行查询, 就可以获得重建Sequence的角本了. 需要导出下面几个系统表的数据. unload table sys.USER$ to sys_user.txt; unload table sys.OBJ$ to sys_obj.txt; unload table sys.SEQ$ to sys_seq.txt; 调用建表角本, 创建表. @USER$_syntax.sql @OBJ$_syntax.sql @SEQ$_syntax.sql 运行sqlldr将数据导入到新的库, 注意不要将这些数据导入到SYS用户下....
AUL恢复Oracle触发器?
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...
AUL恢复Oracle索引结构?
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将数据导入到新的库,...
AUL恢复Oracle存贮过程
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...
Oracle数据恢复服务模式
AUL工具可用于没有备份情况下的Oracle数据恢复, 提供服务的方式有多种, 顺便和用Oracle DUL提供恢复的方式比较了一下. 1, 现场服务. 如果我们相距很近, 如在同一个城市, 或一两小时路程, 并且刚好是休息时间, 则可以提供现场服务. 比如在上海就提供过现场数据恢复服务, 缺点时受时间和地域限制. Oracle DUL恢复者也同样面临这样的问题. 2, 上传下载. 如果我们相距不近, 并且数据库比较小, 则可以用这种方式, 现在Internet的速度也还可以了. 早期都只提供这种工作模式, 缺点是数据的安全性会被受到质凝, 如果数据文件有几个GB大小的话, 上传下载就不是那么快了, 从而导致了整个恢复的时间较长. Oracle DUL恢复者大都想采用这种方法. 3, 远程登录. 在数据文件比较大时, 请允许我远程连接(VPN或Internet直连),...
终极Oracle数据恢复工具 -- AUL
原创工具AUL可以离开Oracle运行环境, 从数据文件中直接读取记录, 当你无法打开数据库(如丢失System表空间, System表空间损坏, 丢失其中一个数据文件, 数据文件时间点不一致, 表被Drop掉或Truncate掉)时, 可以考虑用它来读取剩余数据文件, 将数据恢复成文本文件或Dmp文件, 再装载或导入到新的数据库中. 因此可以被用于没有备份又无法打开数据库情况下的恢复. 经过三年多的研究开发和完善, AUL的功能已经十分完美, 支持文本方式(第二版)及DMP方式(第三版),多种数据类型, 包括BLOB与CLOB(第四版)的恢复, 并在AUL第五版中成功支持压缩表. 支持最新的Oracle 11g版本数据库. 到目前为止, 已经有来自十多个不同地区和国家的数十位客户选择了AUL作为终极恢复工具, 累计恢复的数据量已经超过1TB, 曾收到过1TB数据库的恢复请求, 更被真实地应用于一个2TB数据库的恢复实例中, 以最快的响应速度和最快的恢复速度(最短的案例是一个半小时, 从接到请求到将数据库恢复成文本文件)满足客户的要求. 强烈建议大家做好数据库的备份工作, 欢迎大家在不知道如何备份或在恢复时遇到不明不清楚的问题时向我咨询....
世上8个DUL, 别破解AUL!
这世上有8个DUL类(包括DUL本身)的产品, 大家不一定要找Oracle DUL了, 也不一定要找AUL, 中国人要去破解就去破国外的吧, 别破解AUL了, 最近发现很多写程序的都是大牛, 很容易破AUL, 也可能是我太菜了. Bernard’s Data UnLoader Oracle官方工具, 由Netherlands的Oracle工程师Bernard van Duijnen用C语言写成. 由Oracle支持人员提供服务服务, 价格相当贵. 不过流出来的很多, 一般不能提供远程恢复, 要求现场或传文件的, 都是在用它私下恢复吧. DUDE/jDUL 最早曾经开源(jDUL)过, 后来不开源了, 名称改为DUDE, 由OakTable的成员编写, 网站上可以看到一个团队在维护, 支持Oracle 7, 恢复数据字典(整理建表角本)方面比我的AUL历害, 其他不相上下, Big File表空间大家都没有开始用呢. AnySQL UnLoader (AUL) 由Oracle...
无SYSTEM时的LOB恢复
本想将这种情况下的恢复步骤永远藏在心中的, 因为它在实际生活中太难以恢复了. 看到有人真的遇到了这种情况, 我还是将恢复的步骤写一下吧. 先来创建一个表空间及带BLOB字段表. SQL> CREATE TABLESPACE LOBDATA 2 DATAFILE 'C:\oracle\oradata\db10g\lobdata01.dbf' size 24m 3 extent management local uniform size 128K 4 segment space management manual; Tablespace created. SQL> CREATE TABLE T_LOB (COL1 NUMBER, COL2 BLOB) TABLESPACE LOBDATA; Table created. ...
AUL工具的源代码有多少行?
今天比较好奇地统计了一下AUL源代码的行数, 想想自已这三年以来为这个软件写了多少行代码, 发现并没有我想象的那么多. 以为早到了一万行了, 原来还差一些. DMP格式文件的接口部分. C:\mydul-b5>wc -l dmpfile.* 245 dmpfile.c 41 dmpfile.h 286 total 解释Oracle块格式的部分. C:\mydul-b5>wc -l block.* 5795 block.c 438 block.h 6233 total AUL命令行软件部份. C:\mydul-b5>wc -l mydul.*...
AUL遇到特别的Oracle数据库, 恢复失败!
今天AUL遇到了一个特别的数据, 虽然System表空间都是好的, 但却无法UNLOAD字典信息, 从而无法很好地恢复数据. 第一个特别的现象是, 数据库的第一个数据文件, SYSTEM表空间的第一个数据文件的RFILE#列不为1, 这是我第一次见到. * ts# fno rfn ver bsize blocks filename - ---- ---- ---- --- ----- ---------- ----------------- Y 0 1 4 02 8192 128000 system01.dbf Y 0 10 10 02 8192 64000 system02.dbf 另外AUL所需要读的几个系统表也有特别的地方, 我从DBA_OBJECTS中查这几个表的DATA_OBJECT_ID, 发现他们都很大. 不明白的这些系统字典表的Data...
AUL 5对恢复成DMP格式支持得更好了
为了加上压缩(Compress)表的支持, 完全重写了几个处理块内记录的重要函数, 没想到改完后测试, 发现对DMP格式恢复支持的更好了. 用最新的AUL 4去将"SYS.IND$"恢复成DMP文件, 在导入时发现这个DMP文件不能使用, 遇到了以下错误. import done in UTF8 character set and AL16UTF16 NCHAR character set export client uses US7ASCII character set (possible charset conversion) . importing MYDUL's objects into SH2 . . importing table ...
AUL/MyDUL发展历史回顾
在完成对Compress表的支持后, AUL/MyDUL已经相当完美了. 很有必要来回忆一下它的版本发展历史, 从2004年年底开始构思以来, 已经经历三个春秋了. 很多人知道我这个人也是因为这个工具, 否则我不名一文. 年份 版本 简介 2004年底 1.0.0 因为看见ITPub上Block格式Dump的文章, 加点注释, 就成了精华贴了, 于是想能不能进一步发展一下, 想想中国不备份的数据库那么多, Oracle DUL是那么地难以获得, 就决定动手了. 那时我只会用Java, 于是就用Java去写了, 到后来取名为MyDUL时, 难怪有人硬要说我是抄jDUL开源项目的. 2005 2.0.0 当用Java编的第一版能读出数据后, 发现Java用来处理这个并不方便, 同时也在考虑做成后, 如何保护我的代码, 因为我也用jad轻松地反向编译过少量的Java类, 因此觉得不保险. 另个一个是觉得第一版的程序结构不合理, 要从头再来, 就换成十多年没有用的C了. 同时也接到了从香港来的第一个恢复请求. 2005 3.0.0...
将完成AUL最后一个心愿, 支持Compress表
通过二十分钟的发呆, 进入了研究Oracle压缩(Compress)表的大门, 随之而来的这几天, 研究得很顺利, AUL 5的测试版发布了. 知道Oracle DUL 10版本支持压缩表后, 心中一直就有一个结, 如今这结已经打开, 剩下的只是多做些测试去发现Bug并解决Bug了. 在对Oracle文件格式的研究中, 我找到了自已的DBA激情, 那就是研究Oracle的兴趣, 给平静的DBA生活增加了一些特有的颜色. 由于程序设计当初没有考虑压缩表的需求, 这一次的变动很大, 处理一个数据块内记录的函数(如printDataRows函数), 已经全部重写. 因此在最近一段时间内, AUL 5还不适合作为正式数据恢复的版本, 除非你需要恢复Compress表. 当然欢迎大家来对AUL 5进行测试, 测试方法如下: 1, 创建一个压缩表T_COMPRESS 2, 用AUL 5进行恢复(恢复步骤) 3, 将恢复出来的记录装载到非压缩表T_NOCOMPRESS中 4, SELECT...
发呆, 是研究Oracle的有效方法
上一次在火车上发呆是在研究Log文件格式时, 想了好久都没有想清楚, 于是将一段Log的二进制代码打了张纸, 终于在火车上发呆时想出来了. 今天同样发呆了一次, 不在火车上, 也没有打印出纸来, 而是对着屏幕发呆, 而结果则是快要搞清楚Oracle压缩块的格式了. 上一次研究压缩块已经是一年多以前的事了. 在过去的一年中, 没有为此事着急, 因为压缩块存在很多的Bug, 有的已经修正, 但有的则因为用得人少可能还没有发现, 因此没有压缩表支持的AUL还是得到了大家的欢迎. 不过从Oracle 11g大力推广压缩功能来看, 应当是改进了不少. 根跨版本使用新功能的原则, 在Oracle 11g中应当会有正式开始应用的例子了. 为了让AUL活得更久, 就得支持它. qiuyb版主最近在写DUL的文档, 并确认DUL 10已经支持压缩块了, 看来AUL已经落后一步了. 这也是今天发呆的原因, 没想到还真管用. 预计支持压缩表的AUL 5将会在明年上半年推出. ...
AUL成功使用于一个2TB数据库的恢复
某国外公司的一个2TB的数据仓库坏了, 由于磁盘的问题, 系统表空间上出现了一些块坏. 他们也不是没有备份, 只是最后一次备份是在一个月以前做的, 而最近一段时间装载和处理了很多数据(大约100G左右), 如果直接恢复到一个月以前的备份, 则需要将这些数据重新装载和处理, 将消耗很长的时间. 在数据仓库中, 一般会将数据按时间分表或分区来存放, 因此还是比较容易将最近处理的数据恢复出来的. 他们的领导给他们下了最后命令, 必须在5个工作日之内将这些数据恢复出来, 以供业务部门进行经营分析. 因此他们在对AUL作了一些测试后, 选用它作为这次恢复的解决方案. 这可是AUL有史以来面最大的数据库了, 要恢复其中100g的数据, 数据量也不算少了. 上次遇到一个1TB的, 不过我建议了他们重新生成数据. 第一天我给他们许可证, 第二天我去问他们恢复进行得如何时, 已经只有一张大一点的表还没有恢复出来, 其他大部份数据都已经恢复好了, 速度还是比较快的. 在整个过程中, 我基本上没有作什么技术支持, 只是将英文站点上的几个页面链接发过去, 告诉他们如何申请许可证, 如何一步一步进行恢复. ...
修正AUL恢复ASSM表空间数据时的一个问题
eagle_fan在Linux机器上装了一个Oracle 11g, 今天在测试AUL对Oracle 11g的支持时, 发现了一个ASSM表空间上的问题, 会导致恢复的记录数偏少, 原因是因为ASSM下每一个Extent的第一个数据块不一定是表的数据. 在Free List管理的模式下, 一个Extent中只有两种块, 数据块和没有被使用的块, 并且数据块总在最低端, 为了程序性能, 当AUL检测到第一个非数据块的块时, 就不处理这个Extent了. 然尔在ASSM的情况下, 一个Extent中可能有三种块, bitmap块(type=32), 数据块以及没有使用的块. 当bitmap块在头部时, 就导致了整个Extent中的数据都被跳过了. 不知道有没有朋友遇到这个问题? 通过SCAN EXTENT命令来生成Extent信息时, 则恢复是完全准确的. 这个问题仅限于ASM表空间及没有运行SCAN EXTENT的情况, 对于Free List管理的表空间则没有影响. 以往经历的正式数据恢复都不是ASSM类型的, 这也是这个问题没被早些发现的原因. 对于11g还要进行更详细的测试, 支持11g是没有问题的,...
AUL恢复IOT表的一点改进, 更方便了
以前AUL要恢复IOT, 总是指导人家看这篇文章, 因为IOT表对象本身是没有数据段的, 而是在索引中存放数据, 因此AUL需要先从OBJ$中找出表对象, 从COL$中取得表结构信息, 再从IND$中取得IOT表的主键索引信息和段的信息, 这是理想的情况. 因为用标准C语言来处理这些复杂的关系太累了, 所以没有实现, 如果这个IOT是分区的, 则可能还要复杂, 因为TABPART$和INDPART$也会被卷进来, 如果再有子分区呢? 不过昨天晚上对非分区的IOT表作了一点改进, 因为创建非分区的IOT表时, 索引对象的ID总是表对象的ID再加上一, 有这种规律存在, 就可以稍作改进. DESC命令还是不能显示准确的信息. AUL> desc sys.t_iottest Storage(OBJ#=0 OBJD=0 TS=0 FILE=0 BLOCK=0 CLUSTER=0) No. SEQ INT Column Name Type --- ---...
Oracle Open World期间AUL许可证免费申请
上一次免费申请是在去年的10月份, 因为我太太临产, 不能为大家提供服务, 所以免费. 众多Oracle爱好者期待已久的Open World下击要在上海举行了, 同样不能为大家提供服务, 再次免费, 首先要下载软件(Windows, Linux, Solaris). 申请的方法是, 点击这儿, 然后在用户名处输入"oow2007", 在口令处输入"shanghai", 就会出现申请许可证的页面了. 也请大家关注我的其他工具, 在平常管理中, 它们更有用. 也请大家对于我的工作提出修改意见, Huang Yong就提了一个很好的意见, 我虽然迟了一些时间, 但还是实现了他的要求, 因为我觉得这个功能提得非常好, 估计也是大家很想要的. 大家的意见是我进步的一个根源. 如果你也参加Open World, 我会在会场欢迎你,...
在VMWare上测试了一下AUL对Linux裸设备的支持
将Oracle数据库的数据文件放在裸设备上, 是很正常的事. 不过我的AUL出来将近两年半了, 还从没有测过裸设备. 因为我认为所有Linux/Unix上的裸设备其实也是一个文件, 在程序中就当作普通的文件来操作就行了, 所以就一直没有作测试. Solaris上用Veritas文件系统作的裸设备到是测试过. 先用fdisk创建一个分区, 然后用dd将windows下的一个Oracle文件拷贝到这个分区. 然后用AUL去打开就行了, 如下所示: [root@RH4SRV1 oracle]# ./aul Register Code: 4ZN4-9OVB-EE3Y-OWTN-J5UC AUL : AnySQL UnLoader(MyDUL) for Oracle 8/8i/9i/10g, release 4.0.4 (C) Copyright Lou Fangxin 2005-2007 (AnySQL.net), all rights reserved....
计划AUL 5, 需要解决压缩表的支持问题
这几天, 没有比Oracle 11g更让大家关心了, 从白皮书中看出, Oracle对于压缩技术的支持又上升了一个台阶. 从9i版本引入压缩表以来, 经过10g到11g, 按Oracle历来的表现, 尤其是宣称OLTP级的压缩技术, 这一次应当可以广泛应用了. 因为压缩技术在目前用得很少, 因此当初先考虑LOB的支持而实现了第4版本, 接下来要考虑的是对压缩的支持, 而发布到第5版本, 要以11g中的压缩功能为基础去开发. 在过去的一段时间中, AUL真真实实地帮人解决了一些极端情况下的数据恢复问题, 因此感觉还有继续开发的必要. 另外还要考虑的是对于ASM的支持, 越来越多的系统已经开始使用ASM了. 以及BigFile的支持, 虽然这个功能目前很少人使用. 个人认为, 这个BigFile不如改成一个表空间由最多256个文件组成, 而每个文件的最大大小是现在的4倍, 比如8KB的块大小, 最大的文件大小为256GB, 这样更实用. 不过是越来越搞不动这种研究了, 不知道还能跟上11g这条大船吗?...
测试11g的AUL数据恢复, 好象块格式没有变.
热心网友上传了一个Oracle 11g的数据文件, 我就用AUL去测试了一下AUL能不能恢复11g的数据文件, 解开压缩文件后, 创建一个配置文件db.txt, 包括如下行: 1 1 users01.dbf 接下来运行AUL, 并打开配置文件, 用ORADUMP命令查看一下文件头的属性, 从ver的值可以看出数据库是11g的(十六进制0x0b等于十进制11), 而从fmt的值来看, 0xa2表示还是10g的格式, 0xa等于十进制的10. 如下所示: AUL> open db.txt * ts# fno rfn ver bsize blocks filename - ---- ---- ---- --- ----- ---------- ----------------------- Y 4 4 4 a2 8192 640...
aul4b不再是Beta版了, 这里的B指的是LOB的支持
当你下载AUL的可执行文件, 你会发现Windows下是aul4b.exe, Linux下是aul4b_linux, 而Solaris下是aul4b_solaris, 一很多人认为这是一个Beta版本, 但其实不是了. 这里的4b指的是带LOB支持的版本4. 从发行的版本号4.0.2开始, 就不再是Beta版本了, 因为它已经通过了两次正式的LOB恢复考试. 如果b加在版本号之后, 如下所示的则是Beta测试版. Register Code: TRBR-CCPF-F6KJ-ALTT-MNGQ AUL : AnySQL UnLoader(MyDUL) for Oracle 8/8i/9i/10g, release 4.0.1B (C) Copyright Lou Fangxin 2005-2007 (AnySQL.net), all rights reserved. AUL> exit ...
AUL恢复LOB类型的速度之谜, 慢还是快?
有人用了AUL去恢复LOB数据, 说是速度很慢, 在每份钟只生成了10M数据, 我不是很相信的. 这中间他们可能在估计速度时估计错了. 以我去过两次恢复LOB的经历, 我恢复15000个LOB值, 生成后的大小是600MB, 大约是花了不到5分钟的(记不清了). AUL在恢复LOB数据时, 有两种方式: Inline方式和File方式. 在Inline方式下, LOB的数据和表的记录是放在一个文件中的(默认), 在这种情况下恢复的速度不太可能是1分钟10MB的数据, 因为恢复一般的表时的速度是一秒钟8MB左右(我用SYS.SOURCE$做测试的), 有LOB的情况下, 文件的增长速度应当更快. 在File模式下, 每个LOB值都被存放成一个单独的文件(LOB_xxxxxxxx_xxxx.dat), 然后文本文件中相应的列则记录了这个文件名, 在这种情况下, 1分钟10MB我同意, 可是在计算恢复速度时, 应当加上生成的这些LOB文件的大小. 或者你去计算一下文件文件的记录数, 这表示有多少个LOB值被恢复了, 可以仔细看一下这儿. 如果AUL给人家留下这样错误的印象, 那这是相当不幸的, 对我而言到还好, 对他们而言则是他们错过了最好的恢复数据的方法,...
由一个目录下可以存放多少文件引出的问题
一个目录下(没有子目录)最多可以存放多少个文件? 我现在也不知道答案. 只不过文件太多时, 很不方便, 不能进行ls等操作, 而且访问可能会很慢. 今年总共进行过两次LOB数据类型的恢复, 而且都是恢复成文本格式的, 这样的话, 每一个数据库中的LOB值都被恢复成一个文件, 存放在运行AUL的目录下. 还好这两次恢复出来的文件数不多, 都只有1.2万条左右的记录, 恢复后生成了1.2万和1.5万个文件, 就这样已经让某些目录操作不太方便了. 遇到更多的LOB记录要恢复怎么办? 遇到更多的LOB记录怎么办? 为此在AUL中新增了一个设置选项, 用于设置恢复时LOB文件存放的子目录的个数, 默认值是500, 也就是恢复出来的LOB文件会被存放在最多500个子目录中. 这个值是可以调整的(范围: 100-2000), 采用记录所在的块号和这设置值的余数来确定存放的目录, 这样的话对于同一个设置的恢复, 生成的文件位置是固定的, 但问题可能是不够随机, 不能让LOB文件平均分配到各子目录. 如下所示: AUL> set MAXLOBDIR 1000 Current...
AUL功能改进, 生成建表的SQL文件
在有SYSTEM的情况下, 生成DMP格式时, 会自动包含一个建表的语句, 而在导出成文本文件时, 则没有生成建表语句. 从以往的经历来看, 文本方式的导出更稳定一些, 另外DBA找不表建表语句的情况也常发生, 出于这两点, 我对AUL作了一点改进, 在以文本方式导出时, 自动生成一个建表的SQL文件. 在AUL中早就可以看表结构了: AUL> desc anysql.emp Storage(OBJ#=10560 OBJD=10560 TS=4 FILE=4 BLOCK=627 CLUSTER=0) No. SEQ INT Column Name Type --- --- --- ----------------------------- ---------------- 1 1 1...
今日中午时分收到的一封求救信
最近范错的人比较多, 这不? 就收到了一封求救信. 内容如下: anysql,你好: 我是山东的革命老区临沂人, 非常冒昧打扰你, 我把单位的一个ORACLE数据库弄坏了. 从网上搜索到你开发的工具aul可以直接从DBF中读取数据, 因此就很冒昧的给你这个邮件, 还是关于注册码的事情, 不知道你能否.... 我们这里经济很不好, 尤其是这几年物价飞涨, 能否给个注册码. 非常感谢! 一个希望获得你帮助的小人物. 请大家建议我应当如何做?...
AUL升级, 更改sqlldr控制文件选项的默认值
AUL在恢复成文本格式时, 可以自动生成一个sqlldr的控制文件, 这极大地方便和简化了数据恢复的过程, 在实际的使用中, 遇到了几个sqlldr的问题. 为了方便恢复, 改更了一些默认值. 在本次修改以前, 控制文件的选项为: -- -- Generated by AUL/MyDUL, for table anysql.mem_member -- OPTIONS(DIRECT=TRUE,READSIZE=4194304,ERRORS=-1,ROWS=50000) LOAD DATA 更改后, 取消了DIRECT设置, 采用默认值; 增加了BINDSIZE值; 将READSIZE的值增大了. 新版本的选项如下: -- -- Generated by AUL/MyDUL, for table anysql.mem_member --...
使用iconv来进行CLOB数据的恢复
一个韩国的Oracle数据库, System表空间的文件被删除了需要进行恢复. 还好整个的数据文件的大小只有500MB, 在免费的范围内, 不用交钱他们自已就可以恢复. 但今天被他们问了太多的问题, 有些烦了, 所以我将免费的范围缩小了, 第一, 只能免费打开2个文件了, 原来是4个, 第二, 相对文件号为1的还可免费读取前512MB, 不为1的则只能读取256MB了. 他的数据库中有CLOB字段, 还好值都不大, 而且是Enable Storage In Row的CLOB, 因此虽然丢失了System表空间, 但还是能恢复出CLOB数据的, 他们真是好运啊. 由于使用的字符集是变长的, 因此存放在CLOB中的数据是以Unicode(UCS-2)字符集存放的, 虽然恢复出来了, 但装载前还得将恢复出来的文件进行转换. 由于Unicode用两个字节来存放一个字符, 因此这中间有Byte Edian的问题. 到10g以后, Oracle的CLOB总是用Big Edian的, 而在10g以前, 则看数据库运行的平台, 运行在SUN...
AUL中未用过的恢复删除记录的功能
AUL中有个选项可以试图恢复被删除的记录, 不过这个选项我未没有下式用过, 因为它只适合于没有DELETE的表, 如果这个表本身有DELETE操作, 则这个命令基本上会失败, 这是因为在Oracle中, 记录被打上了DELETE标记后, 那部份空间有可能被重用了, 也有可能引起AUL程序非法退出. 不过在实验室环境中我们还是可以玩一玩的, 下面以EMP表为例: SQL> SELECT COUNT(*) FROM ANYSQL.EMP; COUNT(*) ---------- 14 SQL> DELETE ANYSQL.EMP; 14 rows deleted. SQL> COMMIT; Commit complete. 接下来我运行了一句Checkpoint命令, 然后来作恢复, 恢复时只需要将DELETED_ROWS选项设为TRUE(默认值为False)就行. 如下所示: AUL> unload table...
全套出售AUL/MyDUL, 包括源代码, 请估值!
AUL是本人开发的一个在极端情况下进行Oracle数据恢复的软件, 具有很高的科技含量和一定的商业价值. 什么是极端情况? 第一, 没有备份; 第二, 常规方法无法恢复; 第三, 数据很重要, 但又无法或成本太高而进行重新输入. 如丢失了Oracle的System表空间, System表空间损坏到无法启动的地步, 意外删除表空间或表, 意外截断(Truncate)表等, 在过去的两年中, AUL已经成功地为十几个客户救回了超过300G/几十亿条记录的数据. 现在最新版本已经支持Oracle CLOB/BLOB类型, 已有LOB类型成功恢复的经验, 功能上来说已经相当完善和稳定了. 为什么出售? 1, 本人没有信心和能力去开一个公司; 2, 这样的工具以私人方式经营, 其价值严重被贬值, 通过对比Oracle提供的服务价格和我的价格, 得出这个结论; 3, 一些其他原因; 4, 本人最近需要用钱. 达成交易后出售方的责任: 1,...
DUL有多大啊, 可不可以发一个啊?
去ITPub的数据库区一看, 居然有人翻出了04年的这个贴子, 还引得不少人再次回贴, 要求DUL, d.c.b.a居然现在公开发贴要DUL? 不由得让人细看了发帖人的名字好几遍, 这里最基本的原因是因为发贴时间不够明显, 另外呢我们看贴时也很少注意发贴时间, 总以为冒上来的总是最新的. 话说回来, 当时最后还是没有要到DUL, 估计当时总共的发贴数还不到100吧? 要是当时每个人都被看成一支股票, 我想我到是一支好股票, 两年多的时间, 增值了多少倍? 因为没有搞到, 求人不如求已, 就自已写一个吧, 从2004年10月份开始想的, 11月份动手, 到2005年3月份就出第二版了. 那就是当年引起深入研究是否不符合Oracle版权之争的MyDUL, 也因为那场版权之争, 将名字从MyDUL更改到AUL. 大约几个月后, 又认为使用MyDUL的名字也没有关系, 想改回来, 但又没有完全改回来. I'd like to make some suggestions to...
宣布AUL 3退役, AUL 4开始工作.
AUL 4是在AUL 3的基础上加上了对Oracle BLOB/CLOB数据类型的支持, 于2006年12月份开始修改工作, 于2007年1月份发布了Beta版本. 在经历一次正式的恢复需求后会将Beta版本发布为正式版本, 现在已经到时间了. 不久前成功地为一个外国客户恢复了一个有BLOB字段的表, 总共恢复了12922个图片/PDF/DOC等文件, 恢复出来的数据成功地得到了客户的认同, 图片打开没有问题, 只有少数(小于10个)的PDF文件打开后是空白页, 这就不确定是谁的问题了. 因此郑重宣布AUL 3退役, AUL 4版本正式开始战斗, 最新的版本是4.0.2. 需要非常感谢客户对我的支持, 在这一次恢复中, 原来用的是Beta版本直接拷贝出来的4.0.1版本, 在恢复过程中遇到了两处Bug问题, 客户很仔细很耐心地支持我对Bug的修改, 这种配合精神我在国内的客户中少有遇到. 除了遇到Bug找过我之外, 这位国外客户仔细阅读我的英文Blog上的文档, 没有问过我什么问题, 这一点我们更需要向他们学习了. 这次修复的Bug主要有两处: 1, 在Chained或Migrated行中存放的LOB字段不能恢复. 原因: 没有将LOB索引的信息传给处理Chained和Migrated记录的子程序....
一网友和我确认, 他可以被轻松破解AUL.
一月份在网上发现AUL被破解的信息, 周五早上一网友发给我如下消息: AUL> set licence 00EFBFBF Registered, Elapsed: 725 这证明了AUL的确被破解了! 整个程序中最弱的环节可以就是在这儿了, 虽然这个许可证的模型很好. 我不是计算机科班出生的, 大学时数学这门课还学得特差, 要不也搞个比较复杂的线性代数, 距阵运行等算法进去. 不过破了就破了好了, 连Microsoft的Vista都在几天内遭人破解(Keznews论坛上一个名为"Snooza"成员日前破解了Vista的正版验证程序. 方法很简单: 暴力破解. Snooza所开发的一款软件程序可以生成Windows Vista密钥, 并可以成功激活Vista. 经过该论坛的其他成员测试, 该破解方法是有效的.). 这一破解对我会有什么影响呢? 我想不多. 第一, 破解者说只是个人玩玩而已. 第二, 我会经常改进程序的. 第三, 将暂停AUL用户指南的编写. 第四,...
本周AUL遇到1TB数据库的恢复请求!
周四晚上先将电脑背回家并开机上网, 然后和朋友一起出去吃饭, 回来时发现有陌生人加了我的MSN和Skype, 用英文说是要购买一个AUL的许可证(来自意大利). 将其加入到好友列表中后, 就问他遇到了什么问题, 对方说是有一个1TB大小的数据库坏了, 刚听到时我开心, 这下年终奖有着落了. 当然紧张的心情也是有的, 因为AUL从没有遇到过那么大的数据, 最大的一次是05年70GB的恢复. 于是我继续问他到底是什么回事, 原来是遇到了ORA-01221错误, 这个错误是指Oracle认为这个数据文件的格式是坏的, 从错误手册上可以找到这样的解释: When the database writer opens the datafile, it is accessing a different physical file than the foreground doing the recovery. The timestamp...
关于AUL数据恢复的两件小事 -- 一口价
第一件发生了比较久了, 一个广东东莞的传统行业公司的员工找上我, 说他并不是数据库管理员, 但需要恢复一个数据库. 技术及服务被压迫了这么长一段时间后, 企业应当为这些软件建设支付一定的成本了. 但其实这一步很难, 因为他以个人名义请我帮忙, 理由是不想让公司知道, 而因此丢了饭碗, 并且愿意为此服务支付200元的价格. 东莞是珠三角有名的经济重镇, 作何感想? 最后当然是拒绝了, 我并不想帮私人恢复数据, 因为私人没什么数据需要放在Oracle中. 如果中国的技术人员就这样的活法, 有什么尊严可言? 关于技术人员在公司中的受重视程度, 很多人心里明白. 第二件发生不久, 一个北京的技术出生的老板找上我, 说是要恢复一个比较大的库(超出了AUL免费版的范围了)中的一小部份数据. 我给了一个价格, 后来打了半价, 最后他还是很难同意, 这中间大约已经过了6个小时. 这一段时间内不停地站在他的本次立场上为我设计AUL合理的收费方式, 和我聊这些当然我还是感谢他的, 不管怎么样都是为了AUL好. 但聊到最后, 最大的原因尽然是因为我不肯让一点价, 这个一口价让他感觉到很不爽, 没有享受到在平常买卖中讨价还价的乐趣, 在此之前他已经在这个上面研究了三天了, 我敢保证我出的价格已经很底了,...
AUL版本更新, 对SCAN TABLE命令的增强
今日eygle发现一个AUL的小问题, 在没有SYSTEM表空间时运行"SCAN TABLE"命令的输出中的UNLOAD命令居然没有列的类型信息, 按理说应当是有的. 在仔细思考后, 在本机成功地模拟出类似情况. 这是因为SCAN TABLE命令在跑时, 总是从文件头读到文件未, 当发现有一个块是表的数据或IOT的数据后, 就根据块中记录的记录条数字节来确定是否用这个块为猜测的样本块, 而实际上, 这个记录条数字节中的记录数也包括了已经删除的记录. 假设有一前一后两个数据块都属于同一个表, 在前一个块中的记录都已经被全部清楚掉了, 只有后面一个数据块有真实的数据, 这时运行SCAN TABLE将不能得到列的信息, 因为AUL只扫描了第一个数据块, 并将这个块对应的Data Object ID记录在完成列表中, 下次遇到同样的Data Object ID的块时, 就跳过去了, 因此当扫描到第二个数据块时, AUL就不作这个块的分析了. 为此我在程序中新增了一个计算有效记录数的函数. 有效记录必须是: 1, 字段数大于0的, 以防止所有字段全为空的记录. 2,...
AUL几个命令中RDBA的新表示方式
在AUL中有几个命令(OSDUMP, UNLOAD, ORADUMP, BCHECK, CORRUPT, ROWID)可以用RDBA来指定一个Block的地址, 很多人都知道相对块地址(RDBA, 一个32Bit的不带符号的正数, Relative Data Block Address)其实由文件号(RFILE#, 前10个Bit)和块号(BLOCK#, 后22个Bit)组成, 在DUMP或其他很多地方, 引用RDBA时都是用十六进制的数值来表示的. 在本文之前, 在AUL中不能指定一个十六进制的值, 你必须先换算成十进制的值来指定, 这具有一定的不方便性, 因此我对这个作了一点改进, 可以用0x开始来指定一个十六进制的值. 下面的这个例子来恢复某一个块的记录: AUL> unload object 10102 rdba 0x0180000f column number char char; 2007-01-29 23:38:38 10|ACCOUNTING|NEW...
勾起了对AUL的版权问题的回忆
今天从CSDN上看到的消息, 通过自行开发研制或者反向工程等方式获得的商业秘密, 将不被认定为反不正当竞争法有关条款规定的侵犯商业秘密行为. 2007年1月18日, 最高人民法院发布的第一个涉及不正当竞争案件审理的司法解释明确了以上规则. 据了解, 这一规则最早是在IBM诉微软的案子里确立的, 在中国也是第一次明确. 技术需要学习, 日本就是以反向工程学习欧美技术起家, 然后走上发展道路. 中国刚好就在这个阶段, 立法需要为经济发展现实服务. 看到这个消息, 勾起了我对AUL版本问题的一点回忆. 当时AUL成功地为第一个客户恢复了300百万条记录后, 跑到Google数据库论坛上去发了一个广告贴子, 引起了众多人物纷纷发表不同的意见, 到最后我还出于害怕, 放弃了MyDUL的好名字, 几经周折, 改为AUL. 随后Fenng在他自已的站点上发表了MyDUL的版权问题一文, Kamus在eygle网站上也发了一篇MyDUL是否侵权及引起的思考, 一时间大家都认为MyDUL是违法的, 连我自已也没办法不这么想. 现在想想我这个也不能算是反向工程了, 和MyDUL具有同等作用的工具是DUL, 我并没有去将DUL进行反向编译, 而是完全重新打造的. 你也造相机, 我也跟着造相机, 后来造的就违法了吗? 到现在已经有不少的类DUL工具出现了....
开始编写一本AUL用户指南
AUL从开发到现在已经走过两个年头了, 功能渐渐地走向稳定, 也获得了不少人的关注, 但直到现在还没有一个完整的用户指南, 给AUL的使用者带来了一点的麻烦. 虽然在主页上写了不少的关于如何使用AUL的文章, 但零零碎碎地不容易看懂, 没有条理性. 我的几个朋友早就劝说我写一本AUL的使用方面的文档了, 而我迟迟没有写, 完全是我的错. 从ITPub北京年会加来, 有朋友再劝说我好好写个文档, 我才认识到它的重要性. 经过了两年多路, 就算我自已在使用AUL时也需要在网上寻找以前发过的贴子, 更何况别人呢? 因此在回来的第一个晚上就开始编写这样一个文档了, 到今天已经写了三个章节(下载PDF), 欢迎预览, 如果发现什么文字错误, 或我没有写明白的地方, 请一定要告诉我, 我可以尽量改写. 这份文档将提供PDF格式的免费下载, 先发布中文版本, 经过大家的火眼金睛后, 将会翻译成英文版, 同样发布在站点上下载. 我将尽量在年前完成, 预计的页数将会有100页. 不知道读着会不会让大家很闷. 从未好好写过一从文档. ...
AUL/MyDUL被破解? 算号器惊现网上...
今天在有道Blog搜索中搜索AnySQL单词, 却发现AUL被破解(Crack)的信息出现在网上, 很感荣幸, 我的一个工具竞出现在破解的列表上. 马上存下来做个纪念. 出现在有道搜索结果上的快照(截图): 点进去之后, 又存了一个快照(截图): 不知道他破解用了多长时间, 因为我又要改算法了, 对于这样一个没什么人用的工具, 破解工作是否能取得足够的回报?...
IOT表中段的命名规律, 以及AUL对IOT的支持
AUL对于IOT表的恢复是支持的, 但需要手工修改一下生成的字典信息. 首先来看一下IOT表的数据段的命名规律. 考虑下面两个IOT表: CREATE TABLE T_IOT ( COL1 NUMBER NOT NULL PRIMARY KEY, COL2 VARCHAR2(20) ) ORGANIZATION INDEX; CREATE TABLE T_IOT2 ( COL1 NUMBER NOT NULL CONSTRAINT PK_T_IOT2 PRIMARY KEY, COL2 VARCHAR2(20) )...
AUL 4中如何恢复分区表的LOB字段?
当遇到分区表的LOB字段时, 不能直接进行恢复, 需要修改一下AULOBJ.TXT中的LOB索引分区的名称, 这是由于LOB索引的分区名和表的分区名不同引起的, 而我的程序是假定是具有相同的分区名的. 请看下面的演示, 先创建一个有LOB字段的分区表: SQL> CREATE TABLE T_HASHLOB (COL1 NUMBER, COL2 CLOB) 2 LOB(COL2) STORE AS (DISABLE STORAGE IN ROW) 3 PARTITION BY HASH(COL1) PARTITIONS 2; Table created. 接下来插入几条记录, 交提交, 到SYS用户下进行CHECKPOINT. 在AUL 4中重新UNLOAD系统数据字典后, 用DESC来看一下T_HASHLOB表的情况: AUL>...
AUL 4 Beta程序更新情况 - 2006.12.21
这几天对AUL 4继续进行完善, 比刚发布Beta时的程序已经好多了, 不过版本号还是没有变化. 先来重温一下刚发布时的一些限制吧. 没有经过足够多的测试. 目前的测试仅在10g上进行. 对于CLOB的字符集转换还有些问题. 对LOB Index的访问用Index Full Scan的算法, 需要改进. 对于CHUNK SIZE大于一个数据块的情况还不支持. 到现在又有那些改进呢? 做了更多的测试, 不同大小的CLOB/BLOB, Inline或Outline的 在8i上也做了一些测试 CLOB的字符集转换支持GBK和UTF8. 对LOB Index的访问已经采用Index Range Scan的算法. 可以指定CHUNK SIZE了. 已经对现在的程序充满信心了, 正在等待实践的检验. 留下仅有的一个问题是, 如何支持同一表的LOB的CHUNK大小不同的情况....
AUL 4现阶段对LOB CHUNK的支持情况
通过试验, 发现LOB的一个CHUNK中的所有块必须是在一个Extent中的, 并且是连续的, 不相信的话你可以试试能不能指定CHUNK的大小的值为大于表的Next Extent的值? 基于这个规律, 在AUL 4中增加了对CHUNK的有限支持. 下面上用于测试的两张表, 只有一个字段, 为CLOB类型, 表中只有有一条记录, 内容相同: SQL> SELECT TABLE_NAME,COLUMN_NAME,CHUNK FROM USER_LOBS; TABLE_NAME COLUMN_NAME CHUNK --------------- ------------ ---------- T_CHUNK2 COL1 32768 T_CHUNK1 COL1 16384 接下来用新增的CHUNK选项指定表中所有LOB的CHUNK大小, 单位是数据块, 默认值是1, 从这儿我们可以看出如果一个表中有多个LOB字段, 且CHUNK大小不一样, AUL 4现在还是不支持的. 下面我们将LOB内容导出成独立的文件: AUL> set clob_edian...
在AUL中如何轻松恢复TRUNCATE的表?
不小心Truncate表的事情也是有的, 其中大部份时因为工具连错了库, 从儿跑错了角本. 遇到这种事情而没有备份时怎么办呢? 首先要停止数据库, 将这个表所在的表空间的文件拷贝出来