例如, 在我的笔记本上, 每次启动AUL都得到如下输出.

Register Code: DETO-NODT-JETT-DNMX-DDCN
AUL : AnySQL UnLoader(MyDUL) for Oracle 8/8i/9i/10g/11g, release 5.1.1

(C) Copyright Lou Fangxin 2005-2010 (AnySQL.net), all rights reserved.

AUL>

    这里所说的同一台机器, 并不是指物理的机器, 即使只是操作系统的重装, 也有可能让注册码发生更改, 从而需要新的许可证, 固定许可证方式将对AUL的用户更加有利, 其他平台的AUL也将一步一步进行许可证改造.

    在固定许可证模式下, 你购买AUL时, 不只是得到了一次服务, 更重要的是你真正得到达了一个长期可用的许可证.

Relative Posts:

• 2009/06/09 -- AUL程序上的两处缺陷 (1)
• 2009/04/26 -- 拯救数据, 拯救地球? (9)
• 2008/08/01 -- 终极Oracle数据恢复工具 — AUL (8)
• 2008/07/06 -- 连错库误删100多张表 (9)
• 2008/04/16 -- AUL Sybase数据恢复工具 (4)
• 2008/03/30 -- AUL也走品牌路线? (2)
• 2008/03/28 -- 选择AUL恢复数据的理由 (3)
• 2008/03/19 -- Oracle数据恢复服务模式 (0)
• 2007/11/06 -- 将完成AUL最后一个心愿, 支持Compress表 (2)
• 2009/11/20 -- 首次AUL恢复失败案例 (1)

……
Recover rows from chained block RDBA=29371932 ...
Recover rows from chained block RDBA=29371771 ...
Recover rows from chained block RDBA=29371579 ...
Recover rows from chained block RDBA=29371868 ...
Recover rows from chained block RDBA=29371884 ...
Recover rows from chained block RDBA=29371900 ...
Recover rows from chained block RDBA=29371916 ...
Recover rows from chained block RDBA=29371932 ...
……

    由于要恢复的表中含有LONG RAW字段，里面存放的都是比较大的图片，PDF文档或WORD文档的二进制文件，从1MB到8MB不等，所以需要链接块（Chained Blocks）来用多个块存放一条记录。从上面截取的调试信息中，红色的第一行和最后一行，访问的数据块是相同的，这一点是不能理解的。当我们通过标记第一个块为损坏块后，后面又出现了类似的情况，通过求助于Oracle官方的支持网站，进行资料查找，发现有一个Bug和这种情况息息相关：

Bug 7705591 Corruption with self-referenced row in MSSM tablespace

    这个Bug已经确认会在10.2.0.2和10.2.0.4上遇到，并且目前的所有版本中都可能遇到，Oracle在这个Bug上写明，要到未来版本才能修复。这个Bug详细的英文解说如下：

A chained row (logical row continued in another row) in a table can be corrupted where the next row piece (nrid) points to itself.Data corruption resulting from a lost row piece can occur very intermittently in blocks experiencing high concurrency in MSSM tablespaces (dba_tablespaces.segment_space_management=MANUAL). It is most likely to happen but not limited to tables with a large number of columns (e.g. more than 255 columns). Without the fix of Bug 8720802 tools like DBVERIFY / RMAN / ANALYZE don't detect this logical corruption. The fix for this bug does not repair existent corruptions.

    简单地说就是CHAINED BLOCKS形成了一个环路, 无法跳出去，如果没有打上8720802这个补丁，连Oracle的工具DBV/RMAN/ANALYZE命令等都检测不出这种情况。并且修复这个Bug也不能纠正现有的记录。在Metalink上还有其他一些有关行链接的Bug, 可以用关键字“oracle chained row corruption bug”去搜索，也可能造成记录头的混乱。

    而恢复软件能顺利恢复的基础是，要么块是完好的，要么块能免被检查出来是损坏的，但按照现状，这个Bug引起的问题，很多工具都不能检测到这种情况。AUL现在可以检测出来行链接进行死循环的情况，但无法应对其他一些有关行链接的Bug引起的逻辑损坏，目前来讲逻辑损坏会导致，恢复出来的DMP文件无法导入，引起恢复失败。

Relative Posts:

• 2009/06/09 -- AUL程序上的两处缺陷 (1)
• 2008/12/27 -- AUL并行扫描Extent (1)
• 2008/08/01 -- 终极Oracle数据恢复工具 — AUL (8)
• 2008/05/12 -- Oracle不行再用AUL (7)
• 2008/04/17 -- Oracle DUL不行就用AUL (10)
• 2008/03/26 -- 不是好人, 这么无耻! (24)
• 2008/03/20 -- AUL恢复Oracle视图代码? (0)
• 2008/03/20 -- AUL恢复Oracle Sequence? (0)
• 2008/03/20 -- AUL恢复Oracle触发器? (0)
• 2008/03/20 -- AUL恢复Oracle索引结构? (0)

    当表和索引同名时, 在执行UNLOAD TABLE命令, 是根据对象名及子对象名去定位对象信息的, 因为表和索引同名, 因此要恢复表时, 会错误地取得索引的段信息, 取决于AUL读取字典生成文件时是表信息在前还是索引信息在前. 虽然早就知道表和索引可以同名, 但在自已的经历中, 创建的所有表和索引都是不重名的, 一开始也没有想到这一点. 另外在早期的版本中是不支持IOT的, UNLOAD命令只读取表, 表分区, 表子分区类型的段对象. 后来支持了IOT, 就要多读取索引, 索引分区, 索引子分区类型的段对象, 由于数据重复而引起了这个问题. 这个问题现在已经在程序上做了改进了, 当时的解决方案是生成一个只包表分区, 表子分区类型段信息的AULOBJ字典文件.

    AUL在设计初期, 还曾查阅比较多的数据库, 发现当数据库的数据文件个数小于1000个时, 数据库文件的相对文件号(RFILE)基本上是不会重复出现的, 因此就只根据相对文件号来定位, 可惜我的发现不是真理, 在一个只有几十个文件的数据库中, 居然发现相对文件号重复的情况. 实际上要根据, 表空间号和相对文件号一起来定位, 要在AUL中修复这一点则相当困难. 解决方法是一个表空间一个表空间地恢复, 不过目前为止只遇到最近的这一次, AUL还没有参与过大于1000个数据文件的恢复, 由于这个缺陷会, 当数据分成两个表空间存放, 象IOT与IOT Overflow, 象表与LOB等, 并且这两个表空间中的文件有重复的相对文件号时, AUL将无法恢复数据.

    最近这次恢复了150GB的数据, 以Dmp格式恢复, 都能正常导入, AUL5的改进相当成功.

Relative Posts:

• 2008/08/01 -- 终极Oracle数据恢复工具 — AUL (8)
• 2008/03/19 -- Oracle数据恢复服务模式 (0)
• 2010/01/10 -- 出售AUL固定许可证 (4)
• 2009/11/20 -- 首次AUL恢复失败案例 (1)
• 2009/04/26 -- 拯救数据, 拯救地球? (9)
• 2008/12/27 -- AUL并行扫描Extent (1)
• 2008/07/06 -- 连错库误删100多张表 (9)
• 2008/05/12 -- Oracle不行再用AUL (7)
• 2008/04/17 -- Oracle DUL不行就用AUL (10)
• 2008/04/16 -- AUL Sybase数据恢复工具 (4)

    非洲大陆很有前途, 大洋洲还是一片空白, 还没有为印度的客户恢复过, 不知道以后是不是可以补全一些. 上周五一位昆明的网友跟我说他用AUL没能恢复数据, 给了我远程登录的权限, 用Demo许可证去恢复了一下, 居然98%数据都恢复了, 那位网友就马上下线, 不再和我联系了.

    提供有价值的东西, 可以取得一些回报, 正在被大多数人接受.

Relative Posts:

• 2008/08/01 -- 终极Oracle数据恢复工具 — AUL (8)
• 2008/07/06 -- 连错库误删100多张表 (9)
• 2008/03/28 -- 选择AUL恢复数据的理由 (3)
• 2008/03/19 -- Oracle数据恢复服务模式 (0)
• 2007/11/06 -- 将完成AUL最后一个心愿, 支持Compress表 (2)
• 2010/01/10 -- 出售AUL固定许可证 (4)
• 2009/06/09 -- AUL程序上的两处缺陷 (1)
• 2008/12/27 -- AUL并行扫描Extent (1)
• 2008/08/14 -- 一次被迫免费的恢复 (14)
• 2008/08/13 -- 小心看好你的数据 (5)

SCAN PARALLEL

    并行度为4, 在程序中写死的. 运行命令结束后, 每个进程会生成一个AULEXT文件. 如:

D:\MYDUL>dir AULEXT*
2008-12-27  14:20            21,689 AULEXT.00.TXT
2008-12-27  14:20            13,591 AULEXT.01.TXT
2008-12-27  14:20                0 AULEXT.02.TXT
2008-12-27  14:20                0 AULEXT.03.TXT
2008-12-27  14:20            35,280 AULEXT.TXT

    所有进程结束后, 会合并四个文件的内容到AULEXT.TXT一个文件中. 在多CPU及多物理磁盘的情况下, 全库扫描的速度会提高很多. 目前这个功能仅在Windows版本上有, Linux及Unix的还没有实现.

Relative Posts:

• 2008/08/01 -- 终极Oracle数据恢复工具 — AUL (8)
• 2008/05/12 -- Oracle不行再用AUL (7)
• 2008/04/17 -- Oracle DUL不行就用AUL (10)
• 2008/03/26 -- 不是好人, 这么无耻! (24)
• 2008/03/20 -- AUL恢复Oracle视图代码? (0)
• 2008/03/20 -- AUL恢复Oracle Sequence? (0)
• 2008/03/20 -- AUL恢复Oracle触发器? (0)
• 2008/03/20 -- AUL恢复Oracle索引结构? (0)
• 2008/03/20 -- AUL恢复Oracle存贮过程 (0)
• 2008/03/19 -- Oracle数据恢复服务模式 (0)

set output_style dmp;
set charset 852;
UNLOAD TABLE GX.VIO_FORCE TO TEMP.dmp;

    在导入时, 就一定要用DBA权限用户, 并且指定FROMUSER和TOUSER选项, 才能导回到原来的用户中去.

imp system file=TEMP.dmp fromuser=MYDUL touser=GX

    改进后, 就不需要用DBA权限的用户, 也不需要指定FROMUSER和TOUSER了.

imp gx file=TEMP.dmp

    下面是真实的测试例子.

Export file created by EXPORT:V08.01.07 via conventional path
import done in ZHS16GBK character set and AL16UTF16 NCHAR character set
. importing GX's objects into GX
. importing GX's objects into GX
. . importing table      "VIO_FORCE"          0 rows imported
Import terminated successfully without warnings.

    有少数用户或中间人水平实在比较菜, 用imp导入时不知道如何写fromuser和touser选项, 只好从客户第一出发, 再作改进了.

Relative Posts:

• 2007/11/09 -- AUL 5对恢复成DMP格式支持得更好了 (1)
• 2010/01/10 -- 出售AUL固定许可证 (4)
• 2009/11/20 -- 首次AUL恢复失败案例 (1)
• 2009/06/09 -- AUL程序上的两处缺陷 (1)
• 2009/04/26 -- 拯救数据, 拯救地球? (9)
• 2009/03/31 -- 指定表名导出文本 (0)
• 2008/12/27 -- AUL并行扫描Extent (1)
• 2008/08/01 -- 终极Oracle数据恢复工具 — AUL (8)
• 2008/07/06 -- 连错库误删100多张表 (9)
• 2008/05/15 -- 将dmp数据导入到另一个表 (3)

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

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

    在处理CLOB字段中文以及NCHAR/NVARCHAR字段时，Oracle DUL目前的版本无能为力, 处理无SYSTEM时LOB字段的表, 同样无能为力. 而AUL可以处理所有这些特殊情况.

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

Relative Posts:

• 2008/03/19 -- Oracle数据恢复服务模式 (0)
• 2009/06/09 -- AUL程序上的两处缺陷 (1)
• 2009/04/26 -- 拯救数据, 拯救地球? (9)
• 2008/12/27 -- AUL并行扫描Extent (1)
• 2008/07/06 -- 连错库误删100多张表 (9)
• 2008/05/12 -- Oracle不行再用AUL (7)
• 2008/04/17 -- Oracle DUL不行就用AUL (10)
• 2008/03/28 -- 选择AUL恢复数据的理由 (3)
• 2008/03/26 -- 不是好人, 这么无耻! (24)
• 2008/03/20 -- AUL恢复Oracle视图代码? (0)

    在事件发生后, 立马联系本站, 决定用AUL去恢复数据, 事发情景如下:

1, 事发后立马停止数据库.

2, 数据库在归档方式下, 删表归档文件还在.

3, 开发人员可以提供准确的重建表的语句.

4, 数据文件有十多GB, 有五万个存放在LOB中的图片.

    了解上述情况后, 立马让客户准备远程连接环境, 先是拷贝AIX上的数据文件到Windows上, 由AUL进行跨平台恢复; 然后是将Windows机器挂到Internet上, 由我进行远程操作; 约好晚上八点半开始, 经过三个小时的紧张恢复, 数据全部搞定. 步骤如下:

1, 从归档日志中找到删除的表的信息.

2, 扫描所有的数据文件, 生成Extent Map.

3, 在新的库中建立空表, 以便借用表结构.

4, 进行大部份表的数据恢复.

5, 再次扫描所有文件, 查找LOB索引段头块.

6, 恢复带LOB的少量表.

    能这么顺利完成任务, 也超出我自已的意料之外, 最主要的是删除表时的归档文件还在, 以及能提供准确的重建表的SQL语句, 以及AUL多年恢复Drop类操作的经验基础上的良好设计.

Relative Posts:

• 2009/04/26 -- 拯救数据, 拯救地球? (9)
• 2008/08/01 -- 终极Oracle数据恢复工具 — AUL (8)
• 2008/03/28 -- 选择AUL恢复数据的理由 (3)
• 2008/03/19 -- Oracle数据恢复服务模式 (0)
• 2007/11/06 -- 将完成AUL最后一个心愿, 支持Compress表 (2)
• 2010/01/10 -- 出售AUL固定许可证 (4)
• 2009/06/09 -- AUL程序上的两处缺陷 (1)
• 2009/02/06 -- 归档日志管理不容易 (1)
• 2008/12/27 -- AUL并行扫描Extent (1)
• 2008/08/14 -- 一次被迫免费的恢复 (14)

    原因只有两种, 没有搞明白Oracle DUL这方面的设置参数, 或者是Oracle DUL实在不支持这种数据类型中的中文. CLOB的中文问题, 我还是费了两个晚上搞定的, 这一次的NVARCHAR2问题, 则没有费任何事, 早就支持了. 只是没有用户真的使用这种数据类型, 一直没有发挥作用而已, 没想到一上来又和Oracle DUL PK了一把.

    照这样下去, AUL可以卖给Oracle了, 至少可以卖给Oracle中国, 反正这种事中国遇到的特别多. 只要用心去考虑和做事, 可以做得比原厂更出色啊.

    能PK过Oracle自已的东西, 还是很有轻飘飘的感觉的.

Relative Posts:

• 2008/12/27 -- AUL并行扫描Extent (1)
• 2008/08/01 -- 终极Oracle数据恢复工具 — AUL (8)
• 2008/04/17 -- Oracle DUL不行就用AUL (10)
• 2008/03/26 -- 不是好人, 这么无耻! (24)
• 2008/03/20 -- AUL恢复Oracle视图代码? (0)
• 2008/03/20 -- AUL恢复Oracle Sequence? (0)
• 2008/03/20 -- AUL恢复Oracle触发器? (0)
• 2008/03/20 -- AUL恢复Oracle索引结构? (0)
• 2008/03/20 -- AUL恢复Oracle存贮过程 (0)
• 2008/03/19 -- Oracle数据恢复服务模式 (0)

    其实也只是随便说说而已, 没想到昨天再接到那朋友的电话, 说是Oracle DUL恢复遇到了问题, 客户有CLOB列中存放了很多中文, 用DUL恢复出来后, 这些字段值都成了乱码. 形成这个乱码原因当然是由于Oracle CLOB列的特殊性, 以及DUL作者不是中国人, 所以没有考虑到CLOB中的中文情况. 来咨询AUL是否可以处理这些乱码, 我欣然说可以.

    客户马上联系我, 下载AUL, 在我的指导下很快就恢复了第一张表, CLOB中的中文内容没有大问题, 却有些小问题, 某些地方总是多了一些问号, 这个问题最好可以完美解决. 形成这个问题的原因是, AUL中只支持了GB2312字符集中的常用汉字以及中文符号, 现在大家都用支持更多中文字和中文符号的GBK字符集了, 因此有些不在GB2312字符集中的汉字或符号在转换时就成了问号, 这就是问号的来源.

    要解决这个问题, 就要更改AUL程序, 以支持GBK字符集, 在参考了iconv项目的源代码, 花了大约四个多小时后, 终于将GBK支持加到AUL中, 在笔记本上的Oracle 10g数据中测试了CLOB的中文后, 就投给客户试用了. 还好没有白费这几个小时的苦心研究, 再恢复出来的CLOB值中问号没有了.

    AUL很多次都是在遇到问题后, 立马进行修改, 一年一年变得更完善. 如果用DUL时遇到了CLOB的乱码问题, 请联系AUL吧.

    总之Oracle DUL搞不定的, AUL可以搞定, 因为它可以随时修善改进.

Relative Posts:

• 2008/12/27 -- AUL并行扫描Extent (1)
• 2008/08/01 -- 终极Oracle数据恢复工具 — AUL (8)
• 2008/05/12 -- Oracle不行再用AUL (7)
• 2008/03/26 -- 不是好人, 这么无耻! (24)
• 2008/03/20 -- AUL恢复Oracle视图代码? (0)
• 2008/03/20 -- AUL恢复Oracle Sequence? (0)
• 2008/03/20 -- AUL恢复Oracle触发器? (0)
• 2008/03/20 -- AUL恢复Oracle索引结构? (0)
• 2008/03/20 -- AUL恢复Oracle存贮过程 (0)
• 2008/03/19 -- Oracle数据恢复服务模式 (0)

    用Sybase的数据库朋友可以试试.

Relative Posts:

• 2010/01/10 -- 出售AUL固定许可证 (4)
• 2009/06/09 -- AUL程序上的两处缺陷 (1)
• 2009/04/26 -- 拯救数据, 拯救地球? (9)
• 2008/08/01 -- 终极Oracle数据恢复工具 — AUL (8)
• 2008/07/06 -- 连错库误删100多张表 (9)
• 2008/03/30 -- AUL也走品牌路线? (2)
• 2008/03/28 -- 选择AUL恢复数据的理由 (3)
• 2008/03/19 -- Oracle数据恢复服务模式 (0)
• 2007/11/06 -- 将完成AUL最后一个心愿, 支持Compress表 (2)
• 2009/11/20 -- 首次AUL恢复失败案例 (1)

    1, 比Oracle的恢复服务便宜, 节约成本.

    2, 比Oracle的恢复服务着更快的响应速度.

    3, 和Oracle的恢复服务一样的优质, 并且合法.

    4, 让更少的人知道数据库出现的问题.

    有这些下由, 还不心动吗? 回头一看, 在AUL的支持和驱动下, 已经有500篇文章了.

    曾经有一美国企业因为受不了Oracle的反应速度, 最终选择了AUL作为恢复解决方案, 在等了Oracle几天后, 联系了AUL, 只用了1.5小时, 就将数据恢复回来了.

    许多国外企业的数据库坏了, 也选择AUL来恢复, 合法并且便宜.

Relative Posts:

• 2009/04/26 -- 拯救数据, 拯救地球? (9)
• 2008/08/01 -- 终极Oracle数据恢复工具 — AUL (8)
• 2008/07/06 -- 连错库误删100多张表 (9)
• 2008/03/19 -- Oracle数据恢复服务模式 (0)
• 2007/11/06 -- 将完成AUL最后一个心愿, 支持Compress表 (2)
• 2010/01/10 -- 出售AUL固定许可证 (4)
• 2009/06/09 -- AUL程序上的两处缺陷 (1)
• 2008/12/27 -- AUL并行扫描Extent (1)
• 2008/08/14 -- 一次被迫免费的恢复 (14)
• 2008/08/13 -- 小心看好你的数据 (5)

    那时因为忙于改进和完善软件, 因此没有空去理这件事, 经过了三年的发展, 数十次的恢复经历, 相当完善后. 才有空去了解这件事. 经过从多个网友了解来的信息, 充分信某网站宣称自主开发的MYjDUL其实只是AUL/MyDUL第一版的Java源代码而已, 结果还要说AUL是抄jDUL的, 有些人居然做这么丢脸的事. 因为那一版的程序框架是不成熟的, 没有什么正式的作用, 因此MYjDUL也只不过是一个吓人的名称而已, 没有真正实用的软件, 连个试用版本都没有呢. 很久以前我在网上放出过那份源代码, 几个月前正式放出那份源代码, 看他还怎么叫?

    厚黑学中说做人可以脸皮厚一些, 但也不能厚到这种程度, 和那个打磨汉芯的长江学者有得一比了. 也不知道Oracle为什么不去查一下这种非法盗用DUL去恢复的情况. 强列建议Oracle也用我这种许可证方式, 需要用员工号去申请许可证, 这样就知道是那个内鬼放出去的了.

    另外一个证据是他做不了我的第三第四种恢复方式. 盗用也就算了, 因为是我自已放开的, 再反过来乱咬一下, 就不是那么好了, 还好我没有理你, 将AUL/MyDUL开发到第5版本.

    做事先从做人起, 人不能无耻到这种程度. 比破解AUL/MyDUL的人差多了, 破解还是有技术的.

Relative Posts:

• 2008/12/27 -- AUL并行扫描Extent (1)
• 2008/08/01 -- 终极Oracle数据恢复工具 — AUL (8)
• 2008/05/12 -- Oracle不行再用AUL (7)
• 2008/04/17 -- Oracle DUL不行就用AUL (10)
• 2008/03/20 -- AUL恢复Oracle视图代码? (0)
• 2008/03/20 -- AUL恢复Oracle Sequence? (0)
• 2008/03/20 -- AUL恢复Oracle触发器? (0)
• 2008/03/20 -- AUL恢复Oracle索引结构? (0)
• 2008/03/20 -- AUL恢复Oracle存贮过程 (0)
• 2008/03/19 -- Oracle数据恢复服务模式 (0)

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

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;

    调用建表角本, 创建表.

@USER$_syntax.sql
@OBJ$_syntax.sql
@COL$_syntax.sql
@VIEW$_syntax.sql

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

sqlldr test/test control=USER$_sqlldr.ctl
sqlldr test/test control=OBJ$_sqlldr.ctl
sqlldr test/test control=COL$_sqlldr.ctl
sqlldr test/test control=VIEW$_sqlldr.ctl

    再写个SQL就可以很方便地获得某个用户下视图的代码了. 因为用了SYS_CONNECT_BY_PATH函数, 请在9i或以上版本的数据库上使用.

select
  'CREATE OR REPLACE VIEW '||O.NAME||' ('||
   replace(c.cols,',',','||chr(10))||')'||CHR(10)||
  'as'||chr(10), v.text
from
user$ u, obj$ o, view$ v,
( SELECT COL.OBJ#, COL.COLS
  FROM
  (SELECT
    OBJ#, COL#, substr(SYS_CONNECT_BY_PATH(NAME,','),2) COLS
  FROM COL$
  WHERE COL# > 0
  START WITH COL# = 1
  CONNECT BY PRIOR OBJ# = OBJ# AND PRIOR COL# = COL# - 1 ) COL,
  (SELECT OBJ#, COUNT(*) COLCNT FROM COL$
  WHERE COL# > 0 GROUP BY OBJ#) CN
  WHERE COL.OBJ# = CN.OBJ# AND COL.COL# = CN.COLCNT
) C
where u.user#=o.owner# and o.obj# = c.obj#
  and v.obj# = o.obj# and u.name='用户名'

    这样也算比较方便了. 这个功能要求系统表空间必需存在.

Relative Posts:

• 2008/12/27 -- AUL并行扫描Extent (1)
• 2008/08/01 -- 终极Oracle数据恢复工具 — AUL (8)
• 2008/05/12 -- Oracle不行再用AUL (7)
• 2008/04/17 -- Oracle DUL不行就用AUL (10)
• 2008/03/26 -- 不是好人, 这么无耻! (24)
• 2008/03/20 -- AUL恢复Oracle Sequence? (0)
• 2008/03/20 -- AUL恢复Oracle触发器? (0)
• 2008/03/20 -- AUL恢复Oracle索引结构? (0)
• 2008/03/20 -- AUL恢复Oracle存贮过程 (0)
• 2008/03/19 -- Oracle数据恢复服务模式 (0)

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

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用户下.

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

    再写个SQL就可以很方便地获得重建某个用户下Sequence的代码了.

SELECT
  'CREATE SEQUENCE '|| SEQ_NAME ||
  ' MINVALUE '||minval ||
  ' MAXVALUE '||MAXVAL ||
  ' START WITH '||LASTVAL ||
  ' ' || CYC || ' ' || ORD ||
  DECODE(SIGN(CACHE), 1,' CACHE '|| CACHE, 'NOCACHE') ||
  ';' SEQ_DDL
from
  (select u.name OWNER, o.name SEQ_NAME,
      s.minvalue MINVAL, s.maxvalue MAXVAL,
      s.increment$ INC,
      decode (s.cycle#, 0, 'NOCYCLE', 1, 'CYCLE ') CYC,
      decode (s.order$, 0, 'NOORDER', 1, 'ORDER') ORD,
      s.cache, s.highwater LASTVAL
  from seq$ s, obj$ o, user$ u
  where u.user# = o.owner#
    and o.obj# = s.obj#
    and u.name='用户名')

    这样也算比较方便了. 这个功能要求系统表空间必需存在.

Relative Posts:

• 2008/12/27 -- AUL并行扫描Extent (1)
• 2008/08/01 -- 终极Oracle数据恢复工具 — AUL (8)
• 2008/05/12 -- Oracle不行再用AUL (7)
• 2008/04/17 -- Oracle DUL不行就用AUL (10)
• 2008/03/26 -- 不是好人, 这么无耻! (24)
• 2008/03/20 -- AUL恢复Oracle视图代码? (0)
• 2008/03/20 -- AUL恢复Oracle触发器? (0)
• 2008/03/20 -- AUL恢复Oracle索引结构? (0)
• 2008/03/20 -- AUL恢复Oracle存贮过程 (0)
• 2008/03/19 -- Oracle数据恢复服务模式 (0)