AnySQL.net

    将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> open b.txt
*  ts#  fno  rfn ver bsize     blocks filename
- ---- ---- ---- --- ----- ---------- --------------------------
Y    7    7    7 02   8192       1280 /dev/sdb1

    接下来要测试一下随机的读取, 如果支持则表示没有问题.

AUL> oradump file 7 block 1
RDBA=0x01c00001(7/1),type=0x0b,fmt=0x02,seq=0x01,flag=0x04
DBID=0xc4ecc64a=3303851594,db=XUE,ts#=7,ts=T,file#=7,blksiz=8192, blks=1280, ver=0x08000000, fzy=----

AUL> oradump file 7 block 10
RDBA=0x01c0000a(7/10)=29360138,type=0x06,fmt=0x02,seq=0x01,flag=0x06
seg/obj=0x00001ed9=7897,csc=0x0000.0034bef5,itc=2,typ=1 - DATA
FLG=0x03, fls=0, nxt=0x00000000(0/0)=0
Transaction Slot:
id   xid-usn.slot.wrap   uba-rdba.row.seq   flag lock fsc/scn
---- ------------------- ------------------ ---- ---- ---------------
0x01 0x0003.01d.000000a5 0x00800077.00bb.0c --U-    2 0x0000.0034bef8
0x02 0x0000.000.00000000 0x00000000.0000.00 ----    0 0x0000.00000000
Block Data:
hdsz=92
flag=0x00
ntab=1
nrow=2
ffre=65535
fsbo=0x0072=114
fseo=0x1fc6=8134
avsp=0x1f54=8020
tosp=0x1f54=8020
tab#=  0     nrow=   2     offs=   0
    row#=   0  offs=0x1f85= 8069+  92=0x1fe1= 8161   flag=--H-FL--
    row#=   1  offs=0x1f6a= 8042+  92=0x1fc6= 8134   flag=--H-FL--

    我在VMWare上感觉AUL进行裸文件扫描时有些慢, 一个10M的文件, 恢然用了将近30秒. 不知道是不是因为在VMWare的原因.

    上一次免费申请是在去年的10月份, 因为我太太临产, 不能为大家提供服务, 所以免费.

    众多Oracle爱好者期待已久的Open World下击要在上海举行了, 同样不能为大家提供服务, 再次免费, 首先要下载软件(Windows, Linux, Solaris).

    申请的方法是, 点击这儿, 然后在用户名处输入"oow2007", 在口令处输入"shanghai", 就会出现申请许可证的页面了.

    也请大家关注我的其他工具, 在平常管理中, 它们更有用. 也请大家对于我的工作提出修改意见, Huang Yong就提了一个很好的意见, 我虽然迟了一些时间, 但还是实现了他的要求, 因为我觉得这个功能提得非常好, 估计也是大家很想要的. 大家的意见是我进步的一个根源.

    如果你也参加Open World, 我会在会场欢迎你, 和你一起讨论Oracle.

    以前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
--- --- --- ------------------------ ----------------
  1   1   1 OBJID                    NUMBER(38) NOT NULL
  2   2   2 OBJNAME                  VARCHAR2(30)

    在AULOBJ.TXT文件中找一下这个测试的IOT表的信息吧.

C:\MYDUL>grep T_IOTTEST aulobj.txt
10136,0,T_IOTTEST,,2
10137,0,PK_T_IOTTEST,,1

    再在AUL中来直接进行恢复看看? 这下简单多了.

AUL> UNLOAD TABLE SYS.T_IOTTEST;
2007-08-17 10:14:20
Unload OBJD=10137 FILE=1 BLOCK=28569 CLUSTER=0 ...
2|C_OBJ#
3|I_OBJ#
4|TAB$
5|CLU$
......

    Windows和Linux上的软件已经更新.

    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是没有问题的, 因为11g中数据块的版本代码还是0xa2, 和10g中的一样. 欢迎你在11g上测试AUL工具, 发现一个Bug, 可奖励一个正式的许可证.

    某国外公司的一个2TB的数据仓库坏了, 由于磁盘的问题, 系统表空间上出现了一些块坏. 他们也不是没有备份, 只是最后一次备份是在一个月以前做的, 而最近一段时间装载和处理了很多数据(大约100G左右), 如果直接恢复到一个月以前的备份, 则需要将这些数据重新装载和处理, 将消耗很长的时间. 在数据仓库中, 一般会将数据按时间分表或分区来存放, 因此还是比较容易将最近处理的数据恢复出来的.

    他们的领导给他们下了最后命令, 必须在5个工作日之内将这些数据恢复出来, 以供业务部门进行经营分析. 因此他们在对AUL作了一些测试后, 选用它作为这次恢复的解决方案. 这可是AUL有史以来面最大的数据库了, 要恢复其中100g的数据, 数据量也不算少了. 上次遇到一个1TB的, 不过我建议了他们重新生成数据.

    第一天我给他们许可证, 第二天我去问他们恢复进行得如何时, 已经只有一张大一点的表还没有恢复出来, 其他大部份数据都已经恢复好了, 速度还是比较快的. 在整个过程中, 我基本上没有作什么技术支持, 只是将英文站点上的几个页面链接发过去, 告诉他们如何申请许可证, 如何一步一步进行恢复.

    中国的数据仓库就没有这样的事了, 一个500G的坏掉了, 在OEM中将用户删除了, 三年的数据, 领导说重新从业务系统来生成数据, 只能说明这个数据仓库并不重要. 另外一个200G的数据仓库坏掉了, 磁盘陈列坏了, 拷出来的系统表空间文件中有很多的坏块, 好象也没有选择去恢复.

    还有一个数据库, 一个15G的表空间不知如何被删除了, 只留下了数据文件, 表空间文件用自动增长方式, 在这15G充满了数据. 据说是10月1号左发生的, 到现在还没有恢复, 因为领导还在费用和数据之间做平衡工作.