AnySQL.net

    一个目录下(没有子目录)最多可以存放多少个文件? 我现在也不知道答案. 只不过文件太多时, 很不方便, 不能进行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 MAXLOBDIR is : 1000
AUL>

    在进行恢复时, 就会生成LOBxxxx的子目录, LOB文件将存放在这些子目录下面, 如:

C:\MYDUL\LOBREC>ls
AULCOL.TXT      LOB0245       LOB0394
AULOBJ.TXT      LOB0246       LOB0395
AULTAB.TXT      LOB0247       LOB0396
AULUSR.TXT      LOB0248       LOB0397
LOB0212         LOB0377       LOB0398
LOB0213         LOB0378       LOB0399
LOB0214         LOB0379       LOB0400
LOB0215         LOB0380       LOB0402
LOB0216         LOB0381       LOB0403
LOB0233         LOB0382       LOB0404
LOB0234         LOB0383       LOB0405
LOB0235         LOB0384       LOB0406
LOB0236         LOB0386       LOB0407
LOB0237         LOB0387       LOB0408
LOB0238         LOB0388       LOB0413
LOB0239         LOB0389       T_LOBTEST_sqlldr.ctl
LOB0240         LOB0390       T_LOBTEST_syntax.sql
LOB0242         LOB0391       aul4b.exe
LOB0243         LOB0392       lobtest.txt
LOB0244         LOB0393       t_lobtest.txt

    我测试时的表总共有5千条记录, 有子目录后好看多了, 要不然太多的文件了.

    有人用了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给人家留下这样错误的印象, 那这是相当不幸的, 对我而言到还好, 对他们而言则是他们错过了最好的恢复数据的方法, 浪费了很多的时间. 在基于x86的Linux上跑这程序, 应当是相当快的.

    当你下载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

    特此通告.

    热心网友上传了一个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 users01.dbf
AUL> oradump file 4 block 1
RDBA=0x01000001(4/1),type=0x0b,fmt=0xa2,seq=0x01,flag=0x04
DBID=0x44814ad1=1149323985,db=ORCL,ts#=4,ts=USERS,file#=4, blksiz=8192, blks=640, ver=0x0b100000, fzy=--O-

    由于没有给我SYSTEM文件, 故当作没有SYSTEM的情况来恢复. 运行"SCAN TABLE TO scan_11g.txt"命令, 然后从生成的scan_11g.txt文件中找到如相UNLOAD语句.

CMD:UNLOAD OBJECT 68415 CLUSTER 0 COLUMN  NUMBER VARCHAR VARCHAR TO OBJD0000068415C000.txt;
CMD:UNLOAD OBJECT 68417 CLUSTER 0 COLUMN  NUMBER VARCHAR VARCHAR NUMBER DATE NUMBER NUMBER NUMBER TO OBJD0000068417C000.txt;
CMD:UNLOAD OBJECT 68420 CLUSTER 0 COLUMN  NUMBER NUMBER NUMBER TO OBJD0000068420C000.txt;
CMD:UNLOAD OBJECT 70052 CLUSTER 0 COLUMN  NUMBER VARCHAR VARCHAR NUMBER DATE NUMBER NUMBER NUMBER TO OBJD0000070052C000.txt;

    我仔细看了一下, 列的类型还猜得比较准, 可以直接跑这些命令来恢复其中的数据. 当然等11g出来后, 还得进去更多的测试, 才能正式宣布支持Oracle 11g.

    这几天, 没有比Oracle 11g更让大家关心了, 从白皮书中看出, Oracle对于压缩技术的支持又上升了一个台阶. 从9i版本引入压缩表以来, 经过10g到11g, 按Oracle历来的表现, 尤其是宣称OLTP级的压缩技术, 这一次应当可以广泛应用了.

    因为压缩技术在目前用得很少, 因此当初先考虑LOB的支持而实现了第4版本, 接下来要考虑的是对压缩的支持, 而发布到第5版本, 要以11g中的压缩功能为基础去开发. 在过去的一段时间中, AUL真真实实地帮人解决了一些极端情况下的数据恢复问题, 因此感觉还有继续开发的必要.

    另外还要考虑的是对于ASM的支持, 越来越多的系统已经开始使用ASM了. 以及BigFile的支持, 虽然这个功能目前很少人使用. 个人认为, 这个BigFile不如改成一个表空间由最多256个文件组成, 而每个文件的最大大小是现在的4倍, 比如8KB的块大小, 最大的文件大小为256GB, 这样更实用.

    不过是越来越搞不动这种研究了, 不知道还能跟上11g这条大船吗?