在AnySQL.net中搜索标签(Tags) 'Recovery' 的结果:
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 Sybase数据恢复工具
前段时间想着要发展其他数据库上面的AUL恢复软件, 前段时间联系了一个Sybase上的高手, 开发了AUL for Sybase, 现在提供的是测试版本, 我们也正在努力地完善它. 用Sybase的数据库朋友可以试试....
Log Miner恢复的误区
今天一个网友在用Log Miner恢复时, 发现怎么都恢复不了想要的DML语句, 所有步骤都是正确无误的. execute dbms_logmnr.add_logfile(options =>dbms_logmnr.new,logfilename => ... execute dbms_logmnr.add_logfile(options =>dbms_logmnr.addfile,logfilename =>... EXECUTE dbms_logmnr.start_logmnr(DictFileName=>'.....'); SELECT sql_undo,sql_redo FROM v$logmnr_contents WHERE seg_name=... 我用自已的MyLOG程序去查, 是找到了一条DML语句的, 可是Log Miner怎么不行呢? 你看他为什么要用Log Miner? 1, 表被删除(Drop). 2, 从昨天的dmp中恢复这个表. 3, 生成Log Miner数据字典文件. 4, 用Log...
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数据库的恢复实例中, 以最快的响应速度和最快的恢复速度(最短的案例是一个半小时, 从接到请求到将数据库恢复成文本文件)满足客户的要求. 强烈建议大家做好数据库的备份工作, 欢迎大家在不知道如何备份或在恢复时遇到不明不清楚的问题时向我咨询....
无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. ...
有恢复业务, 你想去做?
在某一台机器上有两个数据库, 简称A库和B库. 有一天向A库加数据文件时, 用了B库中的某一个文件, 因此B库坏了, 某个表空间坏了, 有些表不能访问了. 其他情况如下: 没有任何数据文件备份. 有最近一年的归档日志. 那个文件是在最近一年之内(2007年9月份之前)新建的. 2007年10月26号的某一个日志坏了, Oracle恢复不运去了. 在这个坏的文件上有Extent的表有25个. 2007年10月26后到现在的归档日志大约有几百个. 依我个人意见, 我直接地告诉他们不可能完全(100%)恢复了, 当然可能其他人还有办法了, 他们的领导说了, Oracle一定能全部恢复就能100%恢复. 人家在QQ上不时地问了我三天有关这个恢复的问题了, 解释来解释去, 嫌烦了, 因为我做不到100%恢复, 所以将这个机会共享出来给大家. 有兴趣的可以问我要他们的QQ号, 正急着呢! 估计这几天如果不搞定, 再过几天就过年去了, 没有心思去搞了....
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最后一个心愿, 支持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将会在明年上半年推出. ...
什么情况算是很麻烦的没有System的恢复?
最近国内的数据库不太平安, 首先是磁盘损坏, 刚好坏到了System表空间所在的盘, 当然这是没有System的恢复. 另外还有好多次误删操作引起的问题, 误删单个或几个表, 误删除一个用户, 误删除一整个表空间(数据文件还在), 这些也算是没有System的恢复. 为什么算? 在System表空间中, 我们可以找出以下信息: 表编号, 数据编号, 表名, 列名, 列类型. 丢了System文件, 当然是没有了这些信息了, 那么误删表, 用户和表空间时, 当然也将表的这些信息删除了, 虽然你的数据库是有一个System的表空间, 但没有这些方便恢复的信息, 也就是没有System的恢复了. 如果还保留有删除操作时的归档日志或联机日志, 则可以从这儿分解出表名和数据编号的对应关系, 则恢复要简单得多. 在数据文件中, 我们能找到什么呢? 我们只能找到: 数据编号和记录. 由于没有了System信息, 对于这种恢复,...
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是没有问题的,...
丢失Redo, 如何不用resetlogs打开数据库?
今收到一个控制文件和一堆数据文件, 要在我的笔记本上打开这个库, 我是很不愿意用open resetlogs选项的, 因为控制文件和数据文件是一致的, 是在关闭数据库的情况下备份出来的. 结果发现日志文件原来是在E盘, 而我的笔记本上只有C盘, 直接Clear是不行的, 直接重命名也是不行的, 通过添加新日志组和删除旧日志组也不行, 因为其中有一组是当前Active的, 因此根本就不让删除. SQL> SELECT MEMBER FROM V$LOGFILE; MEMBER --------------------------------------------- E:\ORACLE\PRODUCT\ORADATA\PROD\REDO01.LOG E:\ORACLE\PRODUCT\ORADATA\PROD\REDO02.LOG E:\ORACLE\PRODUCT\ORADATA\PROD\REDO03.LOG 没办法了? 当然是有办法的了, 我们可以简单地骗过Oracle, 方法是我在C盘的相应目录中建了三个空文本文件, 大小全是0, 只是名字和日志文件的一样, 然后就启动到Mount方式, 进行重命名日志文件, 然后再清除每一个日志文件组, 最后就直接打开了数据库, 没有使用open resetlogs选项. ...
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 --- ---...
到低数据是谁的? 是DBA的吗?
今天在MSN有一个人说他将数据库搞坏了, 我问他如何搞坏的, 没有细说, 有可能是在练习dd或bbed这样的软件时搞坏的吧, 总之现在的SYSTEM表空间上有坏块了. 不想让公司知道, 要不然面子上过不去. 问我如何出售AUL的许可证, 他已经用AUL试过了, 可以读出部份数据. 个人以为, 不管发生什么情况, 数据还是公司的, 如果要恢复这些数据, 应当是公司来承担恢复的成本, 而不是让DBA偷偷地去处理掉. 发生这种情况, 作为公司要重新审视很多的事情: 1, 信息对你的公司有多重要? 2, 对你的职业和未来有多重要? 3, 用什么制度来保证数据的安全性和可靠性? 4, 了解手下或公司的DBA常要处理的重要工作吗? 5, 提供了足够的资源来进行数据备份吗? 6, 是否给手下的人提供了培训的机会, 让他们可以轻松胜任工作? 7, 是否有思考, 那些已经存贮信息是最重要的, 那些是次要的? ...
在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....
手工删除DBA_TABLESPACES中的记录后...
最初是在ITPub上看到人家这样的误操作的, 估计谁也没有遇到过这样的事, 不好作出回答. 今天我在自已的机器上试了一下, 10g的数据库, 如下所示: SQL> delete from dba_tablespaces where tablespace_name='USERS'; 1 row deleted. SQL> commit; Commit complete. SQL> alter system checkpoint; System altered. 决定重启一下数据库, 之前当心打不开数据库, 结果数据库还是能打开的, 这样就好多了. 当去查询这个表空间上的数据时, 出现了600错误, 如下所示: SQL> select * from...
测试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...
MyLOG程序对于Drop类误操作恢复的作用
接到过几次由于Drop误操作引起的恢复请求, 在那种情况下, 最主要的问题是没有办法定位被Drop的表的Data Object ID的值. 由于Oracle在执行Drop操作时并不真正地对数据文件清行清理(这是我们能恢复的前提), 从儿当你的应用中有很多的临时表, 并经常Drop来Drop去的话, 在恢复时进行整个数据文件扫描, 会发现很多的Data Object ID, 而你不知道那个是包括了有用的数据. 事实上这种情况下, 恢复的主要式作是去验证这些Data Object ID是不是包含了真正的数据. 现在我们有了MyLOG, 到可以用来做这件事, 当前要求你能提供执行Drop误操作时所用的联机日志或归档日志文件. 在LOGTAB.TXT文件中加入下面一行: 9999,18,OBJ$, 在LOGCOL.TXT文件中加入下面几行: 9999,1,OBJ#,NUMBER 9999,2,DATAOBJ#,NUMBER 9999,3,OWNER#,NUMBER 9999,4,NAME,VARCHAR2 9999,5,NAMESPACE,NUMBER 9999,6,SUBNAME,VARCHAR2 9999,7,TYPE#,NUMBER 9999,8,CTIME,DATE 9999,9,MTIME,DATE...
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中未用过的恢复删除记录的功能
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...
由物化视图Complete刷新引起的数据丢失
今日早上, 在网上看到一篇贴子, 问了如下两个问题: 数据仓库中有2007年之前的数据 问题一: 如何保持erp与数据仓库中2007年数据一致而数据仓库中2007年之前数据不变(以前通过dbms_mview.refresh('xxx','fast'))? 问题二: 我对x物化视图做了一个全部刷新,但是x物化视图中的数据全部变成2007年的数据,以前数据丢失?如阿恢复到刷新前的状态 其中第一个问题是个难题, 现在很多公司都在想这样的一个解决方案, 其实就是一个实时复制方案, 从在的角度来说, 这方面可以用的方案有: 1, Quest公司的SharePlex; 2, DSG公司的RealSync(没有一点印象); 3, Oracle公司的Stream. 前两者都是比较贵的解决方案, Oracle的Stream懂的人少, 而且在9i中还不够稳定. 物化视图并不适合用来归档生产库的数据到历史库, 原来就象第二点所说的那样, 如果进行全部刷新, Oracle会先在目标数据库上运行一个DELETE命令来删除所有的数据(你可以SQL_TRACE一把), 估计这位老兄也是查了资料或翻了贴子后, 觉得物化视图可以做到这一点, 所以这样做了一把, 结果就是数据被删除了. 最近我也一直在想这样的一个解决的方法, 在物化视图中, 用物化视图日志来捕获对表的变更, 是一个比较好的方法(对于负荷不是很高的数据库),...
最有价值的键盘一击, 值220700美金
这个最有价值的一击出自Alaska州政府税收部门, 工程师在做维护工作时, 意外地删除了一个石油公司的帐户, 并且恰好将备份的磁带也格式化了一下. 等发现问题时, 却发现所作的备份根本就不可用. 从300箱纸质档案上重新输入数据. 技术员意外删除数据及格式化含有备份的磁带 被删除数据和石油业的税收有关 70个人花了6个星期来重新录入数据 失误的代价超过220000美金 如果中国公司出现这样的事故, 估计就没有这么值钱了, 因为找重新录入的人员很便宜, 而且可以强制加班. 另外也未必有这么重要的数据. 从DBA的角度, 怎么样就算高级DBA了呢? 我想不需要懂得很多, 如RAC/复制/Streams等知识, 要求对常用的知识了解得比较深刻, 可以将这些常用的知识在特定的场合下自由地运用出来, 做事细心认真, 具有良好的习惯, 能够想到任务可能造成的额外影响, 并提前作好对策, 不能时不时地捅些乱子出来, 有一天和chao_ping聊天时, 我发表了上面的看法. 希望看到这篇后, DBA至少要学会备份和恢复, Tom...