-
加我公众号(orasos)
加我微信(17813235971)
加我QQ(107644445)
标签云
asm恢复 bbed bootstrap$ dul kcbzib_kcrsds_1 kccpb_sanity_check_2 kcratr_nab_less_than_odr MySQL恢复 obet ORA-00312 ORA-00704 ORA-00742 ORA-01110 ORA-01200 ORA-01555 ORA-01578 ORA-01595 ORA-600 2662 ORA-600 2663 ORA-600 3020 ORA-600 4000 ORA-600 4137 ORA-600 4193 ORA-600 4194 ORA-600 16703 ORA-600 kcbzib_kcrsds_1 ORA-600 KCLCHKBLK_4 ORA-600 kcratr_nab_less_than_odr ORA-15042 ORA-15196 ORACLE 12C oracle dul ORACLE PATCH Oracle Recovery Tools oracle加密恢复 oracle勒索 oracle勒索恢复 oracle异常恢复 ORACLE恢复 Oracle 恢复 ORACLE数据库恢复 oracle碎片 OSD-04016 YOUR FILES ARE ENCRYPTED 比特币加密文章分类
- MongoDB (1)
- MongoDB恢复 (1)
- Others (2)
- 中间件 (2)
- WebLogic (2)
- 操作系统 (112)
- 数据库 (1,884)
- DB2 (22)
- MySQL (82)
- Oracle (1,709)
- Data Guard (53)
- EXADATA (8)
- GoldenGate (24)
- ORA-xxxxx (168)
- ORACLE 12C (72)
- ORACLE 18C (6)
- ORACLE 19C (15)
- ORACLE 21C (3)
- Oracle 23ai (8)
- Oracle ASM (73)
- Oracle Bug (8)
- Oracle RAC (56)
- Oracle 安全 (6)
- Oracle 开发 (28)
- Oracle 监听 (29)
- Oracle备份恢复 (662)
- Oracle安装升级 (108)
- Oracle性能优化 (62)
- 专题索引 (5)
- 勒索恢复 (91)
- PostgreSQL (37)
- pdu工具 (7)
- PostgreSQL恢复 (13)
- SQL Server (34)
- SQL Server恢复 (14)
- TimesTen (7)
- 达梦数据库 (5)
- 达梦恢复 (3)
- 生活娱乐 (2)
- 至理名言 (11)
- 虚拟化 (2)
- VMware (2)
- 软件开发 (51)
- Asp.Net (9)
- JavaScript (12)
- PHP (2)
- 小工具 (34)
- MongoDB (1)
-
最近发表
- 记录19c ASM磁盘掉线触发ORA-59048故障处理
- aix平台Oracle数据库由于断电无法启动故障处理
- 断电引起ORA-600 3005故障处理
- 记录一次云存储资源到期之后引起的数据库恢复
- Firebird 损坏数据库数据抢救工具—firebirdext
- Oracle 19c 202610补丁（RUs+OJVM）-19.33
- 由于con$.con#值达到极限，触发数据库增加约束报ORA-600 12807错误
- MongoDB 离线提取工具—mongoext
- .bres勒索病毒加密数据库dmp文件可恢复
- ORA-600 krsm_mrp_rebuild_lf_list.lno_mismatch
- 记录一次0丢失的ORA-00354: 损坏重做日志块标头故障恢复
- 不当数据库恢复操作导致一个月数据丢失
- obet快速修复oracle 位图损坏块
- 不太常见的10.2.0.1的oracle redo损坏恢复
- obet forcecopy功能抢救硬件故障中的数据文件
- kcratr_nab_less_than_odr和system坏块故障处理
- 通过obet 恢复system坏块,打开数据库
- obet dbv功能完整说明
- 分享一例运行在aix上的sap系统数据库恢复过程
- OBET-Oracle Block Editor Tool使用说明
分类目录归档：数据库
truncate table强制终止导致ORA-00600[ktspfundo-2]
朋友的金蝶erp系统异常abort,让我帮忙分析原因.
ORA-00600[ktspfundo-2]错误
Fri Jul 27 08:53:33 2012 Errors in file /u01/oracle/admin/finance/udump/finance_ora_7687.trc: ORA-00600: internal error code, arguments: [ktspfundo-2], [], [], [], [], [], [], [] ORA-01013: user requested cancel of current operation Fri Jul 27 08:53:33 2012 Errors in file /u01/oracle/admin/finance/udump/finance_ora_7687.trc: ORA-00600: internal error code, arguments: [ktspfundo-2], [], [], [], [], [], [], [] ORA-01013: user requested cancel of current operation Fri Jul 27 08:54:16 2012 Errors in file /u01/oracle/admin/finance/udump/finance_ora_7687.trc: ORA-00600: internal error code, arguments: [ktspfundo-2], [], [], [], [], [], [], [] ORA-00600: internal error code, arguments: [ktspfundo-2], [], [], [], [], [], [], [] ORA-01013: user requested cancel of current operation Fri Jul 27 08:57:12 2012 Errors in file /u01/oracle/admin/finance/bdump/finance_smon_4156.trc: ORA-00600: internal error code, arguments: [ktspfundo-2], [], [], [], [], [], [], [] Fri Jul 27 08:57:20 2012 ORACLE Instance finance (pid = 15)-Error 600 encountered while recovering transaction (8, 3) on object 34294107. Fri Jul 27 08:57:20 2012 Errors in file /u01/oracle/admin/finance/bdump/finance_smon_4156.trc: ORA-00600: internal error code, arguments: [ktspfundo-2], [], [], [], [], [], [], [] Fri Jul 27 09:07:14 2012 Errors in file /u01/oracle/admin/finance/bdump/finance_smon_4156.trc: ORA-00600: internal error code, arguments: [ktspfundo-2], [], [], [], [], [], [], [] Fri Jul 27 09:07:15 2012 Errors in file /u01/oracle/admin/finance/bdump/finance_pmon_4130.trc: ORA-00474: SMON process terminated with error
从这里可以大概看出数据库在进行一个参数,然后用户终止该操作导致,导致ORA-00600[ktspfundo-2]错误,然后出现smon回滚,因为回滚失败从而使得数据块down掉
分析trace文件
*** 2012-07-27 08:53:33.293
ksedmp: internal or fatal error
ORA-00600: internal error code, arguments: [ktspfundo-2], [], [], [], [], [], [], []
ORA-01013: user requested cancel of current operation
Current SQL statement for this session:
TRUNCATE TABLE VTC3B8DR2G7J926FWOBK839XOR
----- Call Stack Trace -----
calling call entry argument values in hex
location type point (? means dubious value)
-------------------- -------- -------------------- ----------------------------
ksedst()+31 call ksedst1() 000000000 ? 000000001 ?
7FFF41B0EE70 ? 7FFF41B0EED0 ?
7FFF41B0EE10 ? 000000000 ?
ksedmp()+610 call ksedst() 000000000 ? 000000001 ?
7FFF41B0EE70 ? 7FFF41B0EED0 ?
7FFF41B0EE10 ? 000000000 ?
ksfdmp()+21 call ksedmp() 000000003 ? 000000001 ?
7FFF41B0EE70 ? 7FFF41B0EED0 ?
7FFF41B0EE10 ? 000000000 ?
kgerinv()+161 call ksfdmp() 000000003 ? 000000001 ?
7FFF41B0EE70 ? 7FFF41B0EED0 ?
7FFF41B0EE10 ? 000000000 ?
kgeasnmierr()+163 call kgerinv() 0068966E0 ? 2AE87C6E1168 ?
7FFF41B0EED0 ? 7FFF41B0EE10 ?
000000000 ? 000000000 ?
ktspfundo()+3902 call kgeasnmierr() 0068966E0 ? 2AE87C6E1168 ?
7FFF41B0EED0 ? 7FFF41B0EE10 ?
000000010 ? 00689C0C0 ?
kcoubk()+351 call ktspfundo() 7FFF41B10810 ? 2AE80C800CFA ?
4D6EE6014 ? 000000002 ?
000000010 ? 7FFF41B11128 ?
ktundo()+1208 call kcoubk() 7FFF41B111F8 ? 7FFF41B10810 ?
2AE87E384024 ? 000000002 ?
000000002 ? 000000000 ?
ktubko()+499 call ktundo() 000000001 ? 010E5C341 ?
2AE87E384020 ? 000000058 ?
000008430 ? 7657E9990 ?
ktuabt()+810 call ktubko() 7657E9990 ? 7FFF41B1188C ?
000000002 ? 7FFF41B11648 ?
7FFF41B11570 ? 7FFF41B11870 ?
ktcrab()+292 call ktuabt() 7657E98F8 ? 000000002 ?
000000002 ? 7FFF41B11648 ?
7FFF41B11570 ? 7FFF41B11870 ?
ktccle()+516 call ktcrab() 7657E98F8 ? 000000002 ?
000000002 ? 7FFF41B11648 ?
7FFF41B11570 ? 7FFF41B11870 ?
ksepop()+384 call ktccle() 000000006 ? 000000002 ?
000000002 ? 7FFF41B11648 ?
7FFF41B11570 ? 7FFF41B11870 ?
kgepop()+123 call ksepop() 0068966E0 ? 000000006 ?
000000002 ? 7FFF41B11648 ?
7FFF41B11570 ? 7FFF41B11870 ?
kgesev()+315 call kgepop() 0068966E0 ? 2AE87C6E1168 ?
0000003F5 ? 7FFF41B11648 ?
7FFF41B11570 ? 7FFF41B11870 ?
ksesec0()+186 call kgesev() 0068966E0 ? 2AE87C6E1168 ?
0000003F5 ? 000000000 ?
7FFF41B11B30 ? 7FFF41B11870 ?
ksqcmi()+2322 call ksesec0() 000000000 ? 000000000 ?
000001000 ? 000000000 ?
000000013 ? 000000005 ?
ksqcnv()+496 call ksqcmi() 77E586B88 ? 000000006 ?
00000FFFF ? 00147AE14 ?
7FFF41B126A0 ? 7FFF41B128A8 ?
ksqcov()+44 call ksqcnv() 77E586B88 ? 000000006 ?
000000000 ? 00147AE14 ?
7FFF41B128A8 ? 000000004 ?
kcbo_reuse_obj()+14 call ksqcov() 77E586B68 ? 000000006 ?
09 000000000 ? 00147AE14 ?
7FFF41B128A8 ? 000000004 ?
kcbrbo()+1126 call kcbo_reuse_obj() 7FFF41B12F04 ? 7FFF41B12F0C ?
000000001 ? 00147AE14 ?
7FFF41B128A8 ? 000000004 ?
ktsstrn_segment()+3 call kcbrbo() 7FFF41B12F04 ? 7FFF41B12F0C ?
941 000000001 ? 00147AE14 ?
7FFF41B128A8 ? 000000004 ?
kkbtts_trunc_tbl_se call ktsstrn_segment() 7FFF41B13180 ? 000000000 ?
g()+1018 0020C6444 ? 000000000 ?
7FFF41B14C00 ? 7FFF00000001 ?
kkbtrn()+8156 call kkbtts_trunc_tbl_se 735ACA058 ? 77BC78D18 ?
g() 000000000 ? 000000002 ?
000000000 ? 7FFF41B14C00 ?
opiexe()+15805 call kkbtrn() 735ACA058 ? 000000000 ?
718831208 ? 000000000 ?
000000002 ? 7FFF00000000 ?
opiosq0()+3316 call opiexe() 000000004 ? 000000000 ?
7FFF41B15F48 ? 00000000B ?
000000002 ? 7FFF00000000 ?
kpooprx()+315 call opiosq0() 000000003 ? 00000000E ?
7FFF41B160B8 ? 0000000A4 ?
000000002 ? 7FFF00000000 ?
kpoal8()+799 call kpooprx() 7FFF41B19264 ? 7FFF41B17280 ?
000000029 ? 000000001 ?
000000000 ? 7FFF00000000 ?
opiodr()+984 call kpoal8() 00000005E ? 000000017 ?
7FFF41B19260 ? 000000001 ?
000000001 ? 7FFF00000000 ?
ttcpip()+1012 call opiodr() 00000005E ? 000000017 ?
7FFF41B19260 ? 000000000 ?
0059C09B0 ? 7FFF00000000 ?
opitsk()+1322 call ttcpip() 00689E3B0 ? 7FFF41B17248 ?
7FFF41B19260 ? 000000000 ?
7FFF41B18D58 ? 7FFF41B193C8 ?
opiino()+1026 call opitsk() 000000003 ? 000000000 ?
7FFF41B19260 ? 000000001 ?
000000000 ? 4E58D8C00000001 ?
opiodr()+984 call opiino() 00000003C ? 000000004 ?
7FFF41B1A428 ? 000000000 ?
000000000 ? 4E58D8C00000001 ?
opidrv()+547 call opiodr() 00000003C ? 000000004 ?
7FFF41B1A428 ? 000000000 ?
0059C0460 ? 4E58D8C00000001 ?
sou2o()+114 call opidrv() 00000003C ? 000000004 ?
7FFF41B1A428 ? 000000000 ?
0059C0460 ? 4E58D8C00000001 ?
opimai_real()+163 call sou2o() 7FFF41B1A400 ? 00000003C ?
000000004 ? 7FFF41B1A428 ?
0059C0460 ? 4E58D8C00000001 ?
main()+116 call opimai_real() 000000002 ? 7FFF41B1A490 ?
000000004 ? 7FFF41B1A428 ?
0059C0460 ? 4E58D8C00000001 ?
__libc_start_main() call main() 000000002 ? 7FFF41B1A490 ?
+244 000000004 ? 7FFF41B1A428 ?
0059C0460 ? 4E58D8C00000001 ?
_start()+41 call __libc_start_main() 000723088 ? 000000002 ?
7FFF41B1A5E8 ? 000000000 ?
0059C0460 ? 000000002 ?
--------------------- Binary Stack Dump ---------------------
这里可以得到更加准确的信息,数据库在truncate table的时候,有人异常终止程序,导致数据库出现ORA-00600[ktspfundo-2].查询mos未发现相关bug记录,从这些信息初步判断是因为oracle的bug导致在truncate表的时候异常终止,然后出现该对象上的回滚记录异常(当然truncate本身不需要回滚,但是可能记录一些附带的回滚信息),然后出现对象回滚异常是的数据库down.重启数据库,对象回滚段信息已经自动回滚完成,数据库正常.因为truncate表被异常终止的情况本身不多见,引发该bug更不常见,如果只是偶尔发生一次,建议忽略该错误.当然如果有时间和兴趣,可以提交sr
数据库报ORA-00607/ORA-00600[4194]错误
昨天晚上处理一起比较奇特的ORA-00600[4194]错误的数据库恢复案例,客户数据库刚刚上线,因为一时疏忽没有做备份.谁知天有不测风云,就这样的系统也会出问题(数据库文件总共 5g redo log sequence#=9).这个事故告诉我们:作为dba在任何时候都不要有侥幸心理,备份重于一切
数据库报ORA-00607/ORA-00600[4194]错误
Thu Jul 26 13:21:11 2012 SMON: enabling cache recovery Thu Jul 26 13:21:11 2012 Errors in file /orasvr/admin/mispdata/udump/mispdata_ora_2865.trc: ORA-00600: internal error code, arguments: [4194], [31], [2], [], [], [], [], [] Thu Jul 26 13:21:11 2012 Doing block recovery for file 1 block 18 Block recovery from logseq 3994, block 3 to scn 89979535 Thu Jul 26 13:21:11 2012 Recovery of Online Redo Log: Thread 1 Group 1 Seq 3994 Reading mem 0 Mem# 0: /orasvr/mispdata/redo01.log Block recovery stopped at EOT rba 3994.5.16 Block recovery completed at rba 3994.5.16, scn 0.89979533 Doing block recovery for file 1 block 9 Block recovery from logseq 3994, block 3 to scn 89979532 Thu Jul 26 13:21:11 2012 Recovery of Online Redo Log: Thread 1 Group 1 Seq 3994 Reading mem 0 Mem# 0: /orasvr/mispdata/redo01.log Block recovery completed at rba 3994.5.16, scn 0.89979533 Thu Jul 26 13:21:11 2012 Errors in file /orasvr/admin/mispdata/udump/mispdata_ora_2865.trc: ORA-00604: error occurred at recursive SQL level 1 ORA-00607: Internal error occurred while making a change to a data block ORA-00600: internal error code, arguments: [4194], [31], [2], [], [], [], [], [] Error 604 happened during db open, shutting down database USER: terminating instance due to error 604 Instance terminated by USER, pid = 2865 ORA-1092 signalled during: ALTER DATABASE OPEN...
通过alert日志中,我们可以发现是因为ORA-00600[4194]导致数据库不能被正常open,但是这次不同的是在报ORA-00600之前有ORA-00607的错误出现,根据这个提示,应该是一个基本的数据块有问题导致.而ORA-00600[4194]是因为undo和redo不一致导致.对于本错误放在一起分析,大概的评估是因为内部对象的异常出现ora-607,导致undo和redo不一致出现ORA-00600[4194].
trace文件分析
--dump redo
DUMP OF REDO FROM FILE '/orasvr/mispdata/redo02.log'
Opcodes *.*
DBAs (file#, block#):
(1, 18)
RBAs: 0x000000.00000000.0000 thru 0xffffffff.ffffffff.ffff
SCNs: scn: 0x0000.00000000 thru scn: 0xffff.ffffffff
Times: creation thru eternity
FILE HEADER:
Compatibility Vsn = 169870080=0xa200300
Db ID=658120234=0x273a1e2a, Db Name='MISPDATA'
Activation ID=658142762=0x273a762a
Control Seq=16668=0x411c, File size=102400=0x19000
File Number=2, Blksiz=512, File Type=2 LOG
descrip:"Thread 0001, Seq# 0000003992, SCN 0x0000055c5e3c-0x0000055cac62"
thread: 1 nab: 0x5 seq: 0x00000f98 hws: 0x6 eot: 0 dis: 0
resetlogs count: 0x2d42646a scn: 0x0000.00000001 (1)
resetlogs terminal rcv count: 0x0 scn: 0x0000.00000000
prev resetlogs count: 0x0 scn: 0x0000.00000000
prev resetlogs terminal rcv count: 0x0 scn: 0x0000.00000000
Low scn: 0x0000.055c5e3c (89939516) 07/26/2012 11:17:42
Next scn: 0x0000.055cac62 (89959522) 07/26/2012 13:16:19
Enabled scn: 0x0000.00000001 (1) 08/16/2011 11:50:10
Thread closed scn: 0x0000.055cac61 (89959521) 07/26/2012 11:17:42
Disk cksum: 0x3088 Calc cksum: 0x3088
Terminal recovery stop scn: 0x0000.00000000
Terminal recovery 01/01/1988 00:00:00
Most recent redo scn: 0x0000.00000000
Largest LWN: 0 blocks
End-of-redo stream : No
Unprotected mode
Miscellaneous flags: 0x0
Thread internal enable indicator: thr: 0, seq: 0 scn: 0x0000.00000000
--ORA-00600错误提示
*** 2012-07-26 13:21:11.566
ksedmp: internal or fatal error
ORA-00600: internal error code, arguments: [4194], [31], [2], [], [], [], [], []
Current SQL statement for this session:
update undo$ set name=:2,file#=:3,block#=:4,status$=:5,user#=:6,undosqn=:7,
xactsqn=:8,scnbas=:9,scnwrp=:10,inst#=:11,ts#=:12,spare1=:13 where us#=:1
--ora-607
Error 607 in redo application callback
TYP:0 CLS:16 AFN:1 DBA:0x00400012 OBJ:4294967295 SCN:0x0000.0551610e SEQ: 1 OP:5.1
ktudb redo: siz: 256 spc: 7892 flg: 0x0012 seq: 0x003d rec: 0x02
xid: 0x0000.026.00000035
ktubl redo: slt: 38 rci: 0 opc: 11.1 objn: 15 objd: 15 tsn: 0
Undo type: Regular undo Begin trans Last buffer split: No
Temp Object: No
Tablespace Undo: No
0x00000000 prev ctl uba: 0x00400012.003d.01
prev ctl max cmt scn: 0x0000.0550709b prev tx cmt scn: 0x0000.0550709c
txn start scn: 0xffff.ffffffff logon user: 0 prev brb: 4194318 prev bcl: 0 KDO undo record:
KTB Redo
op: 0x04 ver: 0x01
op: L itl: xid: 0x0000.01e.00000035 uba: 0x00400012.003d.01
flg: C--- lkc: 0 scn: 0x0000.05511296
KDO Op code: URP row dependencies Disabled
xtype: XA flags: 0x00000000 bdba: 0x0040006a hdba: 0x00400069
itli: 1 ispac: 0 maxfr: 4863
tabn: 0 slot: 1(0x1) flag: 0x2c lock: 0 ckix: 0
ncol: 17 nnew: 12 size: 0
col 1: [ 9] 5f 53 59 53 53 4d 55 31 24
col 2: [ 2] c1 02
col 3: [ 2] c1 03
col 4: [ 2] c1 0a
col 5: [ 5] c4 5a 12 5a 14
col 6: [ 1] 80
col 7: [ 4] c3 08 5f 3d
col 8: [ 4] c3 02 38 52
col 9: [ 1] 80
col 10: [ 2] c1 04
col 11: [ 2] c1 02
col 16: [ 2] c1 02
Block after image is corrupt:
buffer tsn: 0 rdba: 0x00400012 (1/18)
scn: 0x0000.0551610e seq: 0x01 flg: 0x04 tail: 0x610e0201
frmt: 0x02 chkval: 0x65f8 type: 0x02=KTU UNDO BLOCK
这里信息比较多:
1.dump redo部分得到file 1 block 18块可能异常
2.ora-600部分可以得出数据库在执行undo$对象update的回滚操作时候报错
3.通过ora-607信息得到update undo$记录对应的数据块是file 1 block 106(dba 0×00400069),在相同数据库版本数据库中查询.也就是说undo$这个回滚段回滚的时候出现错误.
SQL> SELECT OWNER, SEGMENT_NAME, SEGMENT_TYPE, TABLESPACE_NAME, A.PARTITION_NAME 2 FROM DBA_EXTENTS A 3 WHERE FILE_ID = &FILE_ID 4 AND &BLOCK_ID BETWEEN BLOCK_ID AND BLOCK_ID + BLOCKS - 1; Enter value for file_id: 1 old 3: WHERE FILE_ID = &FILE_ID new 3: WHERE FILE_ID = 1 Enter value for block_id: 106 old 4: AND &BLOCK_ID BETWEEN BLOCK_ID AND BLOCK_ID + BLOCKS - 1 new 4: AND 106 BETWEEN BLOCK_ID AND BLOCK_ID + BLOCKS - 1 OWNER ------------------------------ SEGMENT_NAME -------------------------------------------------------------------------------- SEGMENT_TYPE TABLESPACE_NAME PARTITION_NAME ------------------ ------------------------------ ------------------------------ SYS UNDO$ TABLE SYSTEM
4.发现dba 0×00400012发现坏块是file 1 block 18,查询坏块对象为
SQL> SELECT OWNER, SEGMENT_NAME, SEGMENT_TYPE, TABLESPACE_NAME, A.PARTITION_NAME 2 FROM DBA_EXTENTS A 3 WHERE FILE_ID = &FILE_ID 4 AND &BLOCK_ID BETWEEN BLOCK_ID AND BLOCK_ID + BLOCKS - 1; Enter value for file_id: 1 old 3: WHERE FILE_ID = &FILE_ID new 3: WHERE FILE_ID = 1 Enter value for block_id: 18 old 4: AND &BLOCK_ID BETWEEN BLOCK_ID AND BLOCK_ID + BLOCKS - 1 new 4: AND 18 BETWEEN BLOCK_ID AND BLOCK_ID + BLOCKS - 1 OWNER ------------------------------ SEGMENT_NAME -------------------------------------------------------------------------------- SEGMENT_TYPE TABLESPACE_NAME PARTITION_NAME ------------------ ------------------------------ ------------------------------ SYS SYSTEM ROLLBACK SYSTEM
通过这里的分析,大概可以确定这次故障的原因:
因为ROLLBACK(file 1 block 18)坏块,redo 恢复undo 出现异常出现ORA-607,使得undo和redo不一致从而出现ORA-00600[4194],导致undo$(file 1 block 106)中的一条update事务不能被正常提交或者回滚,从而使得该数据库不能被正常打开.
针对这个库因为ROLLBACK异常,使用隐含参数无法屏蔽该回滚段,因为这个数据量非常小,我们选择了挖数据文件.如果数据量比较大,可以通过bbed尝试提交undo$(file 1 block 106)数据块中事务,看人品是否能够正常启动.
DUL挖ORACLE 8.0数据库
老古董的东西,在你一不小心的时候就可能遇到,测试了dul成功挖ORACLE 8.0数据库
创建模拟环境
SVRMGR> select * from v$version;
BANNER
----------------------------------------------------------------
Oracle8 Release 8.0.5.0.0 - Production
PL/SQL Release 8.0.5.0.0 - Production
CORE Version 4.0.5.0.0 - Production
TNS for 32-bit Windows: Version 8.0.5.0.0 - Production
NLSRTL Version 3.3.2.0.0 - Production
5 rows selected.
SVRMGR> create table t_xifenfei
2> as
3> select * from dba_tables;
Statement processed.
SVRMGR> select count(*) from t_xifenfei;
COUNT(*)
----------
183
1 row selected.
SVRMGR> shutdown immediate;
Database closed.
Database dismounted.
ORACLE instance shut down.
dul参数配置
osd_big_endian_flag=false
osd_dba_file_bits=10
osd_c_struct_alignment=32
osd_file_leader_size=1
dc_columns=2000000
dc_tables=10000
dc_objects=1000000
dc_users=400
dc_segments=100000
control_file = control.txt
db_block_size=2048
export_mode=true
compatible=8
file = dump
dul挖数据
C:\dul>dul8.exe dictv8.ddl Data UnLoader 8.0.6.8 - Internal Use Only - on Thu Jul 26 20:08:33 2012 with 64-bit io functions Copyright (c) 1994/2000 Bernard van Duijnen All rights reserved. DUL: Warning: Recreating file "dul.log" Parameter altered Parameter altered Parameter altered Parameter altered . unloading table OBJ$ 2681 rows unloaded . unloading table TAB$ 187 rows unloaded . unloading table COL$ 11181 rows unloaded . unloading table USER$ 23 rows unloaded . unloading table TABPART$ 0 rows unloaded . unloading table IND$ 221 rows unloaded . unloading table ICOL$ 419 rows unloaded . unloading table LOB$ 13 rows unloaded Life is DUL without it C:\dul>dul8.exe Data UnLoader 8.0.6.8 - Internal Use Only - on Thu Jul 26 20:13:44 2012 with 64-bit io functions Copyright (c) 1994/2000 Bernard van Duijnen All rights reserved. DUL: Warning: Recreating file "dul.log" Loaded 23 entries from USER.dat Loaded 2681 entries from OBJ.dat Loaded 188 entries from TAB.dat Loaded 11218 entries from COL.dat Loaded 0 entries from TABPART.dat Loaded 221 entries from IND.dat Loaded 13 entries from LOB.dat Loaded 419 entries from ICOL.dat DUL> unload table chf.t_xifenfei; . unloading table T_XIFENFEI 183 rows unloaded
启动8.0数据库
C:\oracle\ora80\BIN>SVRMGR30.EXE Oracle Server Manager Release 3.0.5.0.0 - Production (c) Copyright 1997, Oracle Corporation. All Rights Reserved. Oracle8 Release 8.0.5.0.0 - Production PL/SQL Release 8.0.5.0.0 - Production SVRMGR> connect internal/xifenfei Connected. SVRMGR> startup ORACLE instance started. Total System Global Area 15077376 bytes Fixed Size 49152 bytes Variable Size 12906496 bytes Database Buffers 2048000 bytes Redo Buffers 73728 bytes Database mounted. Database opened.
imp导入数据
C:\dul>imp chf/xifenfei file=dump001.dmp full=y Import: Release 8.0.5.0.0 - Production on 星期二 11月 1 23:34:36 2011 (c) Copyright 2000 Oracle Corporation. All rights reserved. 连接到: Oracle8 Release 8.0.5.0.0 - Production PL/SQL Release 8.0.5.0.0 - Production 经由常规路径导出由EXPORT:V07.00.07创建的文件 警告: 此对象由 Bernard's DUL 导出, 而不是当前用户 . 正在将Bernard's DUL的对象导入到 CHF . . 正在导入表 "T_XIFENFEI" 183行被导入 成功终止导入，但出现警告。
测试恢复数据
SVRMGR> connect chf/xifenfei
Connected.
SVRMGR> select count(*) from t_xifenfei;
COUNT(*)
----------
183
1 row selected.
再次证明了dul确实异常的强大,第三方的工具在某些方面确实不是它的对手
