在AnySQL.net中搜索标签(Tags) 'DUL' 的结果:
Oracle不行再用AUL
继上次DUL搞不定CLOB中文问题后, 又遇到了NVARCHAR2中文问题, 有人在正式库中使用了这种数据类型, 遇到数据库损坏(System表空间被覆盖)后, 请人用Oracle DUL去搞的, 好象搞不定NVARCHAR2中的中文问题. 原因只有两种, 没有搞明白Oracle DUL这方面的设置参数, 或者是Oracle DUL实在不支持这种数据类型中的中文. CLOB的中文问题, 我还是费了两个晚上搞定的, 这一次的NVARCHAR2问题, 则没有费任何事, 早就支持了. 只是没有用户真的使用这种数据类型, 一直没有发挥作用而已, 没想到一上来又和Oracle DUL PK了一把. 照这样下去, AUL可以卖给Oracle了, 至少可以卖给Oracle中国, 反正这种事中国遇到的特别多. 只要用心去考虑和做事, 可以做得比原厂更出色啊. 能PK过Oracle自已的东西, 还是很有轻飘飘的感觉的....
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/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...
Oracle Open World期间AUL许可证免费申请
上一次免费申请是在去年的10月份, 因为我太太临产, 不能为大家提供服务, 所以免费. 众多Oracle爱好者期待已久的Open World下击要在上海举行了, 同样不能为大家提供服务, 再次免费, 首先要下载软件(Windows, Linux, Solaris). 申请的方法是, 点击这儿, 然后在用户名处输入"oow2007", 在口令处输入"shanghai", 就会出现申请许可证的页面了. 也请大家关注我的其他工具, 在平常管理中, 它们更有用. 也请大家对于我的工作提出修改意见, Huang Yong就提了一个很好的意见, 我虽然迟了一些时间, 但还是实现了他的要求, 因为我觉得这个功能提得非常好, 估计也是大家很想要的. 大家的意见是我进步的一个根源. 如果你也参加Open World, 我会在会场欢迎你,...
计划AUL 5, 需要解决压缩表的支持问题
这几天, 没有比Oracle 11g更让大家关心了, 从白皮书中看出, Oracle对于压缩技术的支持又上升了一个台阶. 从9i版本引入压缩表以来, 经过10g到11g, 按Oracle历来的表现, 尤其是宣称OLTP级的压缩技术, 这一次应当可以广泛应用了. 因为压缩技术在目前用得很少, 因此当初先考虑LOB的支持而实现了第4版本, 接下来要考虑的是对压缩的支持, 而发布到第5版本, 要以11g中的压缩功能为基础去开发. 在过去的一段时间中, AUL真真实实地帮人解决了一些极端情况下的数据恢复问题, 因此感觉还有继续开发的必要. 另外还要考虑的是对于ASM的支持, 越来越多的系统已经开始使用ASM了. 以及BigFile的支持, 虽然这个功能目前很少人使用. 个人认为, 这个BigFile不如改成一个表空间由最多256个文件组成, 而每个文件的最大大小是现在的4倍, 比如8KB的块大小, 最大的文件大小为256GB, 这样更实用. 不过是越来越搞不动这种研究了, 不知道还能跟上11g这条大船吗?...
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...
相信别人,也请相信自己!
今日收到好友在网上捎来一句话, 那个好友和我一样前段时间写了一个和DUL功能类似的程序, 在那个群(27549448)中有人说了这样的一句话: "他是以前有个开源的DUL,用JAVA写的,然后他消化了,然后就自己写了一个". 对于这个群大家应当有印象的, 前几天有人在ITPub和CNOUG上问Truncate了表后如何恢复, 总有那个几个人在顶着说加入到群27549448就可以解决的. 根据确实的消息, 他以前是从Oracle出来的, 拿着Oracle的DUL软件, 然后就建群进行数据恢复了. 本来大家各做各的, 只要最终的用户能找回他们的数据就行了, 不过在一个群中这样说人家的东西, 他自已有什么光彩的呢? 关于国内的类DUL程序是不是在jDUL的基础上, 我想大家也心中清楚的, 网上关于数据块格式的文章已经很多, 缺少的只是整理和耐心而已, 我是04年年底写成的AUL, 我好友是在今年上半年写出来的程序, 用得着去抄人家的吗? 再说国内写这种程序的人, 据我所知都没有在Oracle公司做过, 为什么就不能信任自已, 从儿对别人也信任呢? 希望说这个话的人以后能多接到恢复的单子, 这不正是你说此话的目标吗?...
站内搜索 | Search
总数: 512 | 留言: 1567
- Name: Fangxin Lou
- MSN: anysql©live.com
- Mail:anysql©yahoo.com
anysql©gmail.com - Skype: anysql
- AIM: loufangxin
- Mobile:008615925611590
分类 | Categories
软件下载:
MSN: loufangxin(a)msn.com, Mail: anysql(at)126.com/support(at)iamdba.com, Skype ID:anysql