今天给一个JDE客户做oracle9i forwindows的移机恢复测试(外部审计要求),客户用了我没用过的backup exec做的media management layer(windows平台),客户自己没用它做过恢复测试,代理商的人也没用过,比较折腾,先是jde用户组不对,后面发现找不到rman备份script,搞半天才veritas代理商的人打电话过来说exec没有script(是否事实暂时不知)。
还在处理过程中接到一个电话,说是oracle7.3.4的版本,win2003的操作系统,没有归档,没有备份,已经有5-6个人折腾过了。我也在忙着,所以就让小杨用QQ先过去跟客户联系着。
客户实在耐不住性子,说医院里病人都打起架来了,让我无论如何飞过去,说是常规方法许多工程师已经用过了,非AUL不行,他们已经查到最近的航班。我用dul/AUL恢复过10g、8i、9i的库,oracle7还是头一遭。看着用户这么急,就让他们先传几个文件过来,我边做恢复测试,边试试水。
先是传了system01.dbf和另一个用户数据文件,可是system怎么都读不对,然客户查下状态:
FILE# STATUS CHECKPOINT CREATE_BYT NAME
———- ——- ———- ———- ——————————————————————————–
1 UNKNOWN 202619580 314572800 D:\HISDATA\DATABASE\SYS1ORCL.ORA
2 RECOVER 202619580 104857600 D:\HISDATA\DATABASE\USER_DATA_1.ORA
\……(skip data) 估计是被蹂躏坏了。
无奈,再传,幸亏QQ速度够快(QQ虽然无赖,但是用途还是挺大的)。
再弄,居然还是有问题。
估计是被蹂躏坏了。
无奈,再传,幸亏QQ速度够快(QQ虽然无赖,但是用途还是挺大的)。
果然,很快搞定。但是oracle7下的control写法跟之后的版本不一样,不需要ts#,从7的v$dbfile和v$datafile里也看不到ts#。从sys.file$里是能看到的,后面使用老熊专门为这个case改写的ODU里用到了。
不得不提的是ODU很强大,而且用法比dul简单。
下面简单列列ODU的处理过程:
ODU> help
help —- get command list
spool —- spool information to file
host —- enter os terminal
rowid —- decode rowid components
rdba —- decode RDBA to rfile# and block#
time —- convert number to timestamp
exit —- exit from odu
load config —- load config information from file
open —- load database filename and asm disk list from file
osdump —- dump file format hex
dump —- dump oracle datafile block
unload —- unload data
scan extent —- scan extent
scan disk —- scan asm disk or any disk or disk partition
list —- list schema object,partition,datafile
charset —- get or list supported charset name
简洁,易用。
看看结果吧:
ODU> unload table HIS.YP_BYFF
Unloading table: YP_BYFF,object ID: 2989
Unloading segment,storage(Obj#=2989 DataObj#=2989 TS#=8 File#=9 Block#=667 Clust
er=0)
20991822 rows unloaded
ODU>
ODU>
ODU> unload table HIS.ZY_CFXM
Unloading table: ZY_CFXM,object ID: 3031
Unloading segment,storage(Obj#=3031 DataObj#=3031 TS#=8 File#=9 Block#=7462 Clus
ter=0)
59613327 rows unloaded
回来说说效率,80G的数据量(datafile size)耗时1小时。ODU确实越来越鲁棒了!
anyway,现在具备恢复从Oracle7.3~Oracle11g的无备份数据恢复实力了,but,any anyway,除非你是傻瓜,没备份的还是赶紧备份下吧,没有开归档的尽快开开吧。
最后得提醒一句,据称这个数据库的“损坏”的首犯是 fastcopy,百度百科有介绍的。使用的朋友们需要注意了。从这个case我们仍然可以看到,系统维护规范的重要性,是多么让人厌烦,又多么让人悔不当初啊。
在这个case处理过程中,得到如下人员的直接和间接帮助:dcba、ora-600、老熊、qiuby and yxyup,thanks a lot.
Recent Comments