今天在整理onenote的未归档笔记的时候，看到数据文件头损坏的东西，很久没有弄这个东西了，下面来玩玩数据文件头损坏的修复，下面做了两个实验:1,COPY当前表空间中其它数据文件头来覆盖故障数据文件头，2，COPY其它表空间中数据文件头来覆盖故障数据文件头。
欢迎大家加入ORACLE超级群：17115662 免费解决各种ORACLE问题,以后BLOG将迁移到http://www.htz.pw
1，数据库版本
本实验是基本LINUX平台的，数据库版本如下，不同平台，不同版本是有区别的。
|
www.htz.pw > select * from v$version;
BANNER ——————————————————————————– Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 – 64bit Production PL/SQL Release 11.2.0.3.0 – Production CORE 11.2.0.3.0 Production TNS for Linux: Version 11.2.0.3.0 – Production NLSRTL Version 11.2.0.3.0 – Production |
2，创建测试表空间
|
www.htz.pw > create tablespace htz datafile ‘/oracle/app/oracle/oradata/orcl1123/htz01.dbf’ size 10M; Tablespace created. www.htz.pw > alter tablespace htz add datafile ‘/oracle/app/oracle/oradata/orcl1123/htz02.dbf’ size 10m; Tablespace altered. |
3，数据文件头内容对比
下面只做了同一个表空间中数据文件头的对比，其中需要注意的是，绿色部分是同一个表空间COPY时需要修改的地方，紫色的部分是不同表空间COPY的时候需要增加修改的地方。具体每个字段的含义见bbed kcvfh
|
BBED> p kcvfh struct kcvfh, 860 bytes @0 @0 struct kcvfhbfh, 20 bytes @0 @0 ub1 type_kcbh @0 0x0b @0 0x0b ub1 frmt_kcbh @1 0xa2 @1 0xa2 ub1 spare1_kcbh @2 0x00 @2 0x00 ub1 spare2_kcbh @3 0x00 @3 0x00 ub4 rdba_kcbh @4 0x01800001 @4 0x01c00001 relative database block address（个人感觉这个值由64*kccfhfno+0001） ub4 bas_kcbh @8 0x00000000 @8 0x00000000 ub2 wrp_kcbh @12 0x0000 @12 0x0000 ub1 seq_kcbh @14 0x01 @14 0x01 ub1 flg_kcbh @15 0x04 (KCBHFCKV) @15 0x04 (KCBHFCKV) ub2 chkval_kcbh @16 0x90e2 @16 0x907e ub2 spare3_kcbh @18 0x0000 @18 0x0000 struct kcvfhhdr, 76 bytes @20 @20 ub4 kccfhswv @20 0x00000000 @20 0x00000000 ub4 kccfhcvn @24 0x0b200000 @24 0x0b200000 ub4 kccfhdbi @28 0xd0278802 @28 0xd0278802 text kccfhdbn[0] @32 O @32 O text kccfhdbn[1] @33 R @33 R text kccfhdbn[2] @34 C @34 C text kccfhdbn[3] @35 L @35 L text kccfhdbn[4] @36 1 @36 1 text kccfhdbn[5] @37 1 @37 1 text kccfhdbn[6] @38 2 @38 2 text kccfhdbn[7] @39 3 @39 3 ub4 kccfhcsq @40 0x00001711 @40 0x00001715 ub4 kccfhfsz @44 0x00000500 @44 0x00000500 文件的大小,其实是块的个数(数据文件大小(ls -l)除块的大小再减去1),可以直接dump控制文件 s_blkz kccfhbsz @48 0x00 @48 0x00 ub2 kccfhfno @52 0x0006 @52 0x0007 file number，这里是绝对文件号,可以通过底层表得到 ,也可以在控制文件中得到 ub2 kccfhtyp @54 0x0003 @54 0x0003 file type，03代表数据文件，01，代表控制文件，02代表redo log ,04,backup controlfile 5 backup file,6 temporary db file ub4 kccfhacid @56 0x00000000 @56 0x00000000 ub4 kccfhcks @60 0x00000000 @60 0x00000000 text kccfhtag[0] @64 @64 text kccfhtag[1] @65 @65 text kccfhtag[2] @66 @66 text kccfhtag[3] @67 @67 text kccfhtag[4] @68 @68 text kccfhtag[5] @69 @69 text kccfhtag[6] @70 @70 text kccfhtag[7] @71 @71 text kccfhtag[8] @72 @72 text kccfhtag[9] @73 @73 text kccfhtag[10] @74 @74 text kccfhtag[11] @75 @75 text kccfhtag[12] @76 @76 text kccfhtag[13] @77 @77 text kccfhtag[14] @78 @78 text kccfhtag[15] @79 @79 text kccfhtag[16] @80 @80 text kccfhtag[17] @81 @81 text kccfhtag[18] @82 @82 text kccfhtag[19] @83 @83 text kccfhtag[20] @84 @84 text kccfhtag[21] @85 @85 text kccfhtag[22] @86 @86 text kccfhtag[23] @87 @87 text kccfhtag[24] @88 @88 text kccfhtag[25] @89 @89 text kccfhtag[26] @90 @90 text kccfhtag[27] @91 @91 text kccfhtag[28] @92 @92 text kccfhtag[29] @93 @93 text kccfhtag[30] @94 @94 text kccfhtag[31] @95 @95 ub4 kcvfhrdb @96 0x00000000 @96 0x00000000 struct kcvfhcrs, 8 bytes @100 @100 Datafile creation change# ub4 kscnbas @100 0x003011e2 @100 0x003012ed creation at SCN base在file$.crscnbas,控制文件中也是有的。 ub2 kscnwrp @104 0x0000 @104 0x0000 creation at SCN wrap 在file$.crscnwrp,控制文件也是有的 ub4 kcvfhcrt @108 0x32a8ae70 @108 0x32a8ae81 Datafile creation timestamp,控制文件也可以得到，不过需要计算，个人认为这里不需要修改，这里我一般是通过重建控制文件 下面三行的内容，一般会用于在offline的数据文件打开后的修复会实现，这种情况下不会使用，不过需要了解一下 ub4 kcvfhrlc @112 0x328d111c @112 0x328d111c Resetlogs timestamp也可以从控制文件中得到 struct kcvfhrls, 8 bytes @116 @116 Resetlogs change# ub4 kscnbas @116 0x00220d37 @116 0x00220d37 resetlog scnbase ub2 kscnwrp @120 0x0000 @120 0x0000 reset log scn wrap ub4 kcvfhbti @124 0x00000000 @124 0x00000000 Time the backup started, struct kcvfhbsc, 8 bytes @128 @128 System change number when backup starte ub4 kscnbas @128 0x00000000 @128 0x00000000 ub2 kscnwrp @132 0x0000 @132 0x0000 ub2 kcvfhbth @136 0x0000 @136 0x0000 ub2 kcvfhsta @138 0x0004 (KCVFHOFZ) @138 0x0004 (KCVFHOFZ) (file header status),这里的值比较多，见笔记 struct kcvfhckp, 36 bytes @484 @484 checkpoint相当的信息 struct kcvcpscn, 8 bytes @484 @484 ub4 kscnbas @484 0x003011e3 @484 0x003012ee checkpoint scn base ub2 kscnwrp @488 0x0000 @488 0x0000 checkpoint scn wrap ub4 kcvcptim @492 0x32a8ae70 @492 0x32a8ae81 checkpoint time ub2 kcvcpthr @496 0x0001 @496 0x0001 checkpoint thread union u, 12 bytes @500 @500 thread RBA struct kcvcprba, 12 bytes @500 @500 ub4 kcrbaseq @500 0x0000005e @500 0x0000005e redo sequence ub4 kcrbabno @504 0x0000020b @504 0x00000291 redo block number ub2 kcrbabof @508 0x0010 @508 0x0010 Byte offset，the byte offset into the block at which the redo record starts ub1 kcvcpetb[0] @512 0x02 @512 0x02 ub1 kcvcpetb[1] @513 0x00 @513 0x00 ub1 kcvcpetb[2] @514 0x00 @514 0x00 ub1 kcvcpetb[3] @515 0x00 @515 0x00 ub1 kcvcpetb[4] @516 0x00 @516 0x00 ub1 kcvcpetb[5] @517 0x00 @517 0x00 ub1 kcvcpetb[6] @518 0x00 @518 0x00 ub1 kcvcpetb[7] @519 0x00 @519 0x00 ub4 kcvfhcpc @140 0x00000002 @140 0x00000002 checkpoint_count ub4 kcvfhrts @144 0x00000000 @144 0x00000000 recovered at timstamp ub4 kcvfhccc @148 0x00000001 @148 0x00000001 control file checkpoint count at read before write（cpc-1） struct kcvfhbcp, 36 bytes @152 @152 Backup Checkpoint SCN struct kcvcpscn, 8 bytes @152 @152 ub4 kscnbas @152 0x00000000 @152 0x00000000 ub2 kscnwrp @156 0x0000 @156 0x0000 ub4 kcvcptim @160 0x00000000 @160 0x00000000 ub2 kcvcpthr @164 0x0000 @164 0x0000 union u, 12 bytes @168 @168 struct kcvcprba, 12 bytes @168 @168 ub4 kcrbaseq @168 0x00000000 @168 0x00000000 ub4 kcrbabno @172 0x00000000 @172 0x00000000 ub2 kcrbabof @176 0x0000 @176 0x0000 ub1 kcvcpetb[0] @180 0x00 @180 0x00 ub1 kcvcpetb[1] @181 0x00 @181 0x00 ub1 kcvcpetb[2] @182 0x00 @182 0x00 ub1 kcvcpetb[3] @183 0x00 @183 0x00 ub1 kcvcpetb[4] @184 0x00 @184 0x00 ub1 kcvcpetb[5] @185 0x00 @185 0x00 ub1 kcvcpetb[6] @186 0x00 @186 0x00 ub1 kcvcpetb[7] @187 0x00 @187 0x00 ub4 kcvfhbhz @312 0x00000000 @312 0x00000000 struct kcvfhxcd, 16 bytes @316 @316 ub4 space_kcvmxcd[0] @316 0x00000000 @316 0x00000000 ub4 space_kcvmxcd[1] @320 0x00000000 @320 0x00000000 ub4 space_kcvmxcd[2] @324 0x00000000 @324 0x00000000 ub4 space_kcvmxcd[3] @328 0x00000000 @328 0x00000000 sword kcvfhtsn @332 6 @332 6 tablespace number ub2 kcvfhtln @336 0x0003 @336 0x0003 这个代表表空间名的长度 text kcvfhtnm[0] @338 H @338 H text kcvfhtnm[1] @339 T @339 T text kcvfhtnm[2] @340 Z @340 Z text kcvfhtnm[3] @341 @341 text kcvfhtnm[4] @342 @342 text kcvfhtnm[5] @343 @343 text kcvfhtnm[6] @344 @344 text kcvfhtnm[7] @345 @345 text kcvfhtnm[8] @346 @346 text kcvfhtnm[9] @347 @347 text kcvfhtnm[10] @348 @348 text kcvfhtnm[11] @349 @349 text kcvfhtnm[12] @350 @350 text kcvfhtnm[13] @351 @351 text kcvfhtnm[14] @352 @352 text kcvfhtnm[15] @353 @353 text kcvfhtnm[16] @354 @354 text kcvfhtnm[17] @355 @355 text kcvfhtnm[18] @356 @356 text kcvfhtnm[19] @357 @357 text kcvfhtnm[20] @358 @358 text kcvfhtnm[21] @359 @359 text kcvfhtnm[22] @360 @360 text kcvfhtnm[23] @361 @361 text kcvfhtnm[24] @362 @362 text kcvfhtnm[25] @363 @363 text kcvfhtnm[26] @364 @364 text kcvfhtnm[27] @365 @365 text kcvfhtnm[28] @366 @366 text kcvfhtnm[29] @367 @367 ub4 kcvfhrfn @368 0x00000006 @368 0x00000007 relative file number struct kcvfhrfs, 8 bytes @372 @372 The SCN at which the recovery of this file will be complete ub4 kscnbas @372 0x00000000 @372 0x00000000 ub2 kscnwrp @376 0x0000 @376 0x0000 ub4 kcvfhrft @380 0x00000000 @380 0x00000000 struct kcvfhafs, 8 bytes @384 @384 absolute fuzzy scn, 即Minimum PITR SCN ub4 kscnbas @384 0x00000000 @384 0x00000000 ub2 kscnwrp @388 0x0000 @388 0x0000 ub4 kcvfhbbc @392 0x00000000 @392 0x00000000 ub4 kcvfhncb @396 0x00000000 @396 0x00000000 ub4 kcvfhmcb @400 0x00000000 @400 0x00000000 ub4 kcvfhlcb @404 0x00000000 @404 0x00000000 ub4 kcvfhbcs @408 0x00000000 @408 0x00000000 ub2 kcvfhofb @412 0x0000 @412 0x0000 ub2 kcvfhnfb @414 0x0000 @414 0x0000 ub4 kcvfhprc @416 0x328d0f49 @416 0x328d0f49 prev reset logs count struct kcvfhprs, 8 bytes @420 @420 prev reset logs SCN ub4 kscnbas @420 0x00220d33 @420 0x00220d33 ub2 kscnwrp @424 0x0000 @424 0x0000 struct kcvfhprfs, 8 bytes @428 @428 ub4 kscnbas @428 0x00000000 @428 0x00000000 ub2 kscnwrp @432 0x0000 @432 0x0000 ub4 kcvfhtrt @444 0x00000000 @444 0x00000000 |
4，COPY相同表空间其它的数据文件头
|
www.htz.pw > alter tablespace htz add datafile ‘/oracle/app/oracle/oradata/orcl1123/htz03.dbf’ size 11M;
Tablespace altered. BBED> info File# Name Size(blks) —– —- ———- 1 /oracle/app/oracle/oradata/orcl1123/system01.dbf 0 2 /oracle/app/oracle/oradata/orcl1123/sysaux01.dbf 0 3 /oracle/app/oracle/oradata/orcl1123/undotbs1.dbf 0 4 /oracle/app/oracle/oradata/orcl1123/users01.dbf 0 5 /oracle/app/oracle/oradata/orcl1123/undotbs2.dbf 0 6 /oracle/app/oracle/oradata/orcl1123/htz01.dbf 0 7 /oracle/app/oracle/oradata/orcl1123/htz02.dbf 0 8 /oracle/app/oracle/oradata/orcl1123/undotbs3.dbf 0 9 /oracle/app/oracle/oradata/orcl1123/htz03.dbf 0
BBED> set mode edit MODE Edit
BBED> copy file 9 block 1 to file 7 block 1; Warning: contents of previous BIFILE will be lost. Proceed? (Y/N) y File: /oracle/app/oracle/oradata/orcl1123/htz02.dbf (7) Block: 1 Offsets: 0 to 511 Dba:0x01c00001 ———————————————————————— 0ba20000 01004002 00000000 00000104 4a910000 00000000 0000200b 028827d0 4f52434c 31313233 1b170000 80050000 00200000 09000300 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 a2183000 00000000 63bca832 1c118d32 370d2200 00000000 00000000 00000000 00000000 00000400 02000000 00000000 01000000 00000000 00000000
www.htz.pw > startup force ORACLE instance started.
Total System Global Area 237998080 bytes Fixed Size 2227216 bytes Variable Size 197133296 bytes Database Buffers 33554432 bytes Redo Buffers 5083136 bytes Database mounted. ORA-01122: database file 7 failed verification check ORA-01110: data file 7: ‘/oracle/app/oracle/oradata/orcl1123/htz02.dbf’ ORA-01210: data file header is media corrupt 这里已经看到，报数据文件头损坏了 |
dump控制文件，可以得到正常时数据文件头中一些信息，这里假设控制文件是正常的，其实需要的信息，我们也可以从底层表中获取
|
DATA FILE #7: name #11: /oracle/app/oracle/oradata/orcl1123/htz02.dbf creation size=1280 block size=8192 status=0xe head=11 tail=11 dup=1 tablespace 6, index=7 krfil=7 prev_file=6 unrecoverable scn: 0x0000.00000000 01/01/1988 00:00:00 Checkpoint cnt:2 scn: 0x0000.003012ee 06/10/2014 23:38:41 Stop scn: 0xffff.ffffffff 06/10/2014 23:38:41 Creation Checkpointed at scn: 0x0000.003012ed 06/10/2014 23:38:41 thread:1 rba:(0x5e.291.10) enabled threads: 01000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 ……………………………………………………………… Offline scn: 0x0000.00000000 prev_range: 0 Online Checkpointed at scn: 0x0000.00000000 thread:0 rba:(0x0.0.0) enabled threads: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 ……………………………………………………………… Hot Backup end marker scn: 0x0000.00000000 aux_file is NOT DEFINED Plugged readony: NO Plugin scnscn: 0x0000.00000000 Plugin resetlogs scn/timescn: 0x0000.00000000 01/01/1988 00:00:00 Foreign creation scn/timescn: 0x0000.00000000 01/01/1988 00:00:00 Foreign checkpoint scn/timescn: 0x0000.00000000 01/01/1988 00:00:00 Online move state: 0 |
下面开始bbed修改内容
4.1 修改rdba_kcbh
rdba_kcbh由8位组成，前4位为绝对文件号*64，后4位由块号组成
|
SQL> select 7*64 from dual;
7*64 ———- 448
SQL> @10to16.sql Enter value for number10: 448 old 1: select to_char(‘&number10′,’xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx’) from dual new 1: select to_char(‘448′,’xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx’) from dual
TO_CHAR(‘448’,’XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX ——————————————— 1c0
BBED> set offset 4 OFFSET 4
BBED> dump File: /oracle/app/oracle/oradata/orcl1123/htz02.dbf (7) Block: 1 Offsets: 4 to 13 Dba:0x01c00001 ———————————————————————— 01004002 00000000 0000
<32 bytes per line>
BBED> modify /x c001 offset 6 File: /oracle/app/oracle/oradata/orcl1123/htz02.dbf (7) Block: 1 Offsets: 6 to 15 Dba:0x01c00001 ———————————————————————— c0010000 00000000 0104
<32 bytes per line>
BBED> p kcvfhbfh.rdba_kcbh ub4 rdba_kcbh @4 0x01c00001 |
4.2 修改数据文件大小
数据文件头中的数据文件大小就是OS上看到的大小–8192，8192这个值可能不一样，可以见V$datafile
|
SQL> select 10493952/8192-1 from dual;
10493952/8192-1 ————— 1280
SQL> @10to16.sql Enter value for number10: 1280 old 1: select to_char(‘&number10′,’xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx’) from dual new 1: select to_char(‘1280′,’xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx’) from dual
TO_CHAR(‘1280’,’XXXXXXXXXXXXXXXXXXXXXXXXXXXXX ——————————————— 500
BBED> p kcvfhhdr.kccfhfsz ub4 kccfhfsz @44 0x00000580
BBED> modify /x 0005 offset 44 File: /oracle/app/oracle/oradata/orcl1123/htz02.dbf (7) Block: 1 Offsets: 44 to 53 Dba:0x01c00001 ———————————————————————— 00050000 00200000 0900
<32 bytes per line>
BBED> p kcvfhhdr.kccfhfsz ub4 kccfhfsz @44 0x00000500 |
4.3 修改文件号
文件号分为绝对文件号与相对文件号
|
修改决对 BBED> p kcvfhhdr.kccfhfno ub2 kccfhfno @52 0x0009
BBED> modify /x 07 offset 52 File: /oracle/app/oracle/oradata/orcl1123/htz02.dbf (7) Block: 1 Offsets: 52 to 61 Dba:0x01c00001 ———————————————————————— 07000300 00000000 0000
<32 bytes per line>
BBED> p kcvfhhdr.kccfhfno ub2 kccfhfno @52 0x0007
修改相对文件号
BBED> p kcvfhrfn ub4 kcvfhrfn @368 0x00000009
BBED> modify /x 07 offset 368 File: /oracle/app/oracle/oradata/orcl1123/htz02.dbf (7) Block: 1 Offsets: 368 to 377 Dba:0x01c00001 ———————————————————————— 07000000 00000000 0000
<32 bytes per line>
BBED> p kcvfhrfn ub4 kcvfhrfn @368 0x00000007 |
4.4 修改创建时的SCN
|
BBED> p kcvfhcrs struct kcvfhcrs, 8 bytes @100 ub4 kscnbas @100 0x003018a2 ub2 kscnwrp @104 0x0000
BBED> modify /x ed12 offset 100 File: /oracle/app/oracle/oradata/orcl1123/htz02.dbf (7) Block: 1 Offsets: 100 to 109 Dba:0x01c00001 ———————————————————————— ed123000 00000000 63bc
<32 bytes per line>
BBED> modify /x 3000 offset 102 File: /oracle/app/oracle/oradata/orcl1123/htz02.dbf (7) Block: 1 Offsets: 102 to 111 Dba:0x01c00001 ———————————————————————— 30000000 000063bc a832
<32 bytes per line>
BBED> p kcvfhcrs struct kcvfhcrs, 8 bytes @100 ub4 kscnbas @100 0x003012ed ub2 kscnwrp @104 0x0000 |
4.5 修改checkpoint_count
|
修改checkpoint count的值， BBED> p kcvfhcpc ub4 kcvfhcpc @140 0x00000002 这里kcvfhcpc的值与控制文件中一致 |
4.6 修改完成
通过上面几步的修改，基本上就可以实现我们的功能了
|
BBED> sum apply Check value for File 7, Block 1: current = 0x9805, required = 0x9805
BBED> verify DBVERIFY – Verification starting FILE = /oracle/app/oracle/oradata/orcl1123/htz02.dbf BLOCK = 1
DBVERIFY – Verification complete
Total Blocks Examined : 1 Total Blocks Processed (Data) : 0 Total Blocks Failing (Data) : 0 Total Blocks Processed (Index): 0 Total Blocks Failing (Index): 0 Total Blocks Empty : 0 Total Blocks Marked Corrupt : 0 Total Blocks Influx : 0 Message 531 not found; product=RDBMS; facility=BBED |
4.7 打开数据库
|
www.htz.pw > alter database open; alter database open * ERROR at line 1: ORA-01122: database file 7 failed verification check ORA-01110: data file 7: ‘/oracle/app/oracle/oradata/orcl1123/htz02.dbf’ ORA-01202: wrong incarnation of this file – wrong creation time
这个报错的原因是因为创建时间不正确导致的
www.htz.pw > select file#,status,error from v$datafile_header;
FILE# STATUS ERROR ———- ——- —————————————————————– 1 ONLINE 2 ONLINE 3 ONLINE 4 ONLINE 5 ONLINE 6 ONLINE 7 ONLINE WRONG FILE CREATE 8 ONLINE 9 ONLINE
9 rows selected. 这里是我没有计算时间的原因 [oracle@www.htz.pw sql]$ls *create*con*.sh create_controlfile_sql.sh [oracle@www.htz.pw sql]$./create_controlfile_sql.sh please input direcotry default /tmp:
please input file name default control.ctl:
Database altered.
下面我们来创建一下控制文件 www.htz.pw > @/tmp/control.ctl ORACLE instance started.
Total System Global Area 237998080 bytes Fixed Size 2227216 bytes Variable Size 197133296 bytes Database Buffers 33554432 bytes Redo Buffers 5083136 bytes
Control file created.
Media recovery complete.
Database altered.
已经数据库已经正常OPEN了。 Tablespace altered. |
5，COPY不同表空间的数据文件头的块
这里选择的是USERS这个表空间来测试，使用SYSAUX表空间中数据文件头来覆盖USERS中的数据文件头的信息
|
BBED> copy file 2 block 1 to file 4 block 1; File: /oracle/app/oracle/oradata/orcl1123/users01.dbf (4) Block: 1 Offsets: 0 to 9 Dba:0x01000001 ———————————————————————— 0ba20000 01008000 0000
<32 bytes per line>
www.htz.pw > alter system switch logfile;
System altered.
www.htz.pw > /
System altered.
www.htz.pw > / alter system switch logfile * ERROR at line 1: ORA-03113: end-of-file on communication channel Process ID: 20945 Session ID: 1 Serial number: 3 |
dump控制文件号
|
DATA FILE #4: name #9: /oracle/app/oracle/oradata/orcl1123/users01.dbf creation size=0 block size=8192 status=0xe head=9 tail=9 dup=1 tablespace 4, index=4 krfil=4 prev_file=0 unrecoverable scn: 0x0000.00000000 01/01/1988 00:00:00 Checkpoint cnt:388 scn: 0x0000.003067d3 06/11/2014 02:38:05 Stop scn: 0xffff.ffffffff 06/11/2014 00:38:20 Creation Checkpointed at scn: 0x0000.000049e7 09/17/2011 09:46:40 thread:0 rba:(0x0.0.0) enabled threads: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 ………………………………….. 00000000 00000000 00000000 00000000 00000000 00000000 Offline scn: 0x0000.00000000 prev_range: 0 Online Checkpointed at scn: 0x0000.00000000 thread:0 rba:(0x0.0.0) enabled threads: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 …………………………………… Hot Backup end marker scn: 0x0000.00000000 aux_file is NOT DEFINED Plugged readony: NO Plugin scnscn: 0x0000.00000000 Plugin resetlogs scn/timescn: 0x0000.00000000 01/01/1988 00:00:00 Foreign creation scn/timescn: 0x0000.00000000 01/01/1988 00:00:00 Foreign checkpoint scn/timescn: 0x0000.00000000 01/01/1988 00:00:00 Online move state: 0 |
|
www.htz.pw > alter database open; alter database open * ERROR at line 1: ORA-01122: database file 4 failed verification check ORA-01110: data file 4: ‘/oracle/app/oracle/oradata/orcl1123/users01.dbf’ ORA-01210: data file header is media corrupt |
这里可以看到数据文件头损坏的报错。
5.1 修改rdba_kcbh
方法见上面
5.2 修改文件号
方法见上面
5.3 修改数据文件大小
方法见上面
5.4 修改创建时的SCN
方法见上面
5.5 修改checkpoint_count
方法见上面
5.7 修改表空间名字信息
|
修改表空间名的长度 ub2 kcvfhtln @336 0x0006 BBED> modify /x 05 offset 336 File: /oracle/app/oracle/oradata/orcl1123/users01.dbf (4) Block: 1 Offsets: 336 to 345 Dba:0x01000001 ———————————————————————— 05005359 53415558 0000
<32 bytes per line> 修改表空间名字 SQL> select dump(‘USERS’,16) from dual;
DUMP(‘USERS’,16) —————————- Typ=96 Len=5: 55,53,45,52,53 BBED> p kcvfhtln ub2 kcvfhtln @336 0x0005
BBED> modify /c USERS offset 338 File: /oracle/app/oracle/oradata/orcl1123/users01.dbf (4) Block: 1 Offsets: 338 to 347 Dba:0x01000001 ———————————————————————— 55534552 53580000 0000 BBED> modify /x 00 offset 343 File: /oracle/app/oracle/oradata/orcl1123/users01.dbf (4) Block: 1 Offsets: 343 to 352 Dba:0x01000001 ———————————————————————— 00000000 00000000 0000
<32 bytes per line>
BBED> dump offset 338 File: /oracle/app/oracle/oradata/orcl1123/users01.dbf (4) Block: 1 Offsets: 338 to 347 Dba:0x01000001 ———————————————————————— 55534552 53000000 0000
<32 bytes per line> 修改表空间号 BBED> p kcvfhtsn sword kcvfhtsn @332 1
BBED> modify /x 04 offset 332 File: /oracle/app/oracle/oradata/orcl1123/users01.dbf (4) Block: 1 Offsets: 332 to 341 Dba:0x01000001 ———————————————————————— 04000000 05005553 4552
<32 bytes per line>
BBED> p kcvfhtsn sword kcvfhtsn @332 4 |
5.8 修改完成
|
BBED> sum apply Check value for File 4, Block 1: current = 0x23ce, required = 0x23ce
BBED> verify DBVERIFY – Verification starting FILE = /oracle/app/oracle/oradata/orcl1123/users01.dbf BLOCK = 1
DBVERIFY – Verification complete
Total Blocks Examined : 1 Total Blocks Processed (Data) : 0 Total Blocks Failing (Data) : 0 Total Blocks Processed (Index): 0 Total Blocks Failing (Index): 0 Total Blocks Empty : 0 Total Blocks Marked Corrupt : 0 Total Blocks Influx : 0 Message 531 not found; product=RDBMS; facility=BBED |
|
www.htz.pw > alter database open; alter database open * ERROR at line 1: ORA-01122: database file 4 failed verification check ORA-01110: data file 4: ‘/oracle/app/oracle/oradata/orcl1123/users01.dbf’ ORA-01202: wrong incarnation of this file – wrong creation time |
重建控制文件后，再次打开数据文件
|
www.htz.pw > recover database; Media recovery complete. www.htz.pw > alter database open; alter database open * ERROR at line 1: ORA-01092: ORACLE instance terminated. Disconnection forced ORA-01177: data file does not match dictionary – probably old incarnation ORA-01110: data file 4: ‘/oracle/app/oracle/oradata/orcl1123/users01.dbf’ Process ID: 11269 Session ID: 1 Serial number: 3 |
这里触发了ORA-01177，01177报错的原因：数据文件头中的创建SCN大于FILE$中存放的SCN
|
BBED> set block 233 BLOCK# 233
BBED> map File: /oracle/app/oracle/oradata/orcl1123/system01.dbf (1) Block: 233 Dba:0x004000e9 ———————————————————— KTB Data Block (Table/Cluster)
struct kcbh, 20 bytes @0
struct ktbbh, 48 bytes @20
struct kdbh, 14 bytes @68
struct kdbt[1], 4 bytes @82
sb2 kdbr[9] @86
ub1 freespace[5686] @104
ub1 rowdata[2398] @5790
ub4 tailchk @8188
BBED> x /rnn *kdbr[3] rowdata[2031] @7821 ————- flag@7821: 0x2c (KDRHFL, KDRHFF, KDRHFH) lock@7822: 0x00 cols@7823: 11
col 0[2] @7824: 4 col 1[2] @7827: 2 col 2[3] @7830: 640 col 3[2] @7834: 4 col 4[2] @7837: 4 col 5[5] @7840: 4194302 col 6[3] @7846: 160 col 7[1] @7850: 0 col 8[4] @7852: 18919 col 9[0] @7857: *NULL* col 10[5] @7858: 16777218
www.htz.pw > select to_char(18919,’xxxxxxxx’) from dual;
TO_CHAR(1 ——— 49e7
这里不知道是什么原因，反正这里看到的创建的SCN与FILE$中的SCN值是一样的。 ub4 kcvfhrdb @96 0x00000000 struct kcvfhcrs, 8 bytes @100 ub4 kscnbas @100 0x000049e7 ub2 kscnwrp @104 0x0000
下面我们把FILE$里面的值增加大一点，原因遇到过一次，报相同的错误，最后把SCN改到比FILE$中小后，问题就解决了。 BBED> x /rn *kdbr[3] rowdata[2031] @7821 ————- flag@7821: 0x2c (KDRHFL, KDRHFF, KDRHFH) lock@7822: 0x00 cols@7823: 11
col 0[2] @7824: 4 col 1[2] @7827: 2 col 2[3] @7830: 640 col 3[2] @7834: 4 col 4[2] @7837: 4 col 5[5] @7840: 4194302 col 6[3] @7846: 160 col 7[1] @7850: 0 col 8[4] @7852: 18919 col 9[0] @7857: *NULL* col 10[5] @7858: 16777218
BBED> set offset 7852 OFFSET 7852
BBED> dump count 10 File: /oracle/app/oracle/oradata/orcl1123/system01.dbf (1) Block: 233 Offsets: 7852 to 7861 Dba:0x004000e9 ———————————————————————— 04c3025a 14ff05c4 114e
<32 bytes per line>
BBED> set offset 7856 OFFSET 7856
BBED> dump File: /oracle/app/oracle/oradata/orcl1123/system01.dbf (1) Block: 233 Offsets: 7856 to 7865 Dba:0x004000e9 ———————————————————————— 14ff05c4 114e4913 2c01
<32 bytes per line>
BBED> modify /x 16 File: /oracle/app/oracle/oradata/orcl1123/system01.dbf (1) Block: 233 Offsets: 7856 to 7865 Dba:0x004000e9 ———————————————————————— 16ff05c4 114e4913 2c01
<32 bytes per line>
再次创建控制文件，故障仍然存在 BBED> set file 1 block 233 FILE# 1 BLOCK# 233
BBED> x /rn *kdbr[3] rowdata[2031] @7821 ————- flag@7821: 0x2c (KDRHFL, KDRHFF, KDRHFH) lock@7822: 0x00 cols@7823: 11
col 0[2] @7824: 4 col 1[2] @7827: 2 col 2[3] @7830: 640 col 3[2] @7834: 4 col 4[2] @7837: 4 col 5[5] @7840: 4194302 col 6[3] @7846: 160 col 7[1] @7850: 0 col 8[4] @7852: 18921 col 9[0] @7857: *NULL* col 10[5] @7858: 16777218 BBED> modify /x e949 offset 100 File: /oracle/app/oracle/oradata/orcl1123/users01.dbf (4) Block: 1 Offsets: 100 to 109 Dba:0x01000001 ———————————————————————— e9490000 00000000 6877
<32 bytes per line>
BBED> p kcvfhcrs struct kcvfhcrs, 8 bytes @100 ub4 kscnbas @100 0x000049e9 ub2 kscnwrp @104 0x0000
BBED> sum apply Check value for File 4, Block 1: current = 0xd308, required = 0xd308
BBED> verify DBVERIFY – Verification starting FILE = /oracle/app/oracle/oradata/orcl1123/users01.dbf BLOCK = 1
DBVERIFY – Verification complete
Total Blocks Examined : 1 Total Blocks Processed (Data) : 0 Total Blocks Failing (Data) : 0 Total Blocks Processed (Index): 0 Total Blocks Failing (Index): 0 Total Blocks Empty : 0 Total Blocks Marked Corrupt : 0 Total Blocks Influx : 0 Message 531 not found; product=RDBMS; facility=BBED
www.htz.pw > @/tmp/control.ctl ORACLE instance started.
Total System Global Area 237998080 bytes Fixed Size 2227216 bytes Variable Size 197133296 bytes Database Buffers 33554432 bytes Redo Buffers 5083136 bytes
Control file created.
Media recovery complete.
Database altered. 数据库已经正常打开
Tablespace altered.
其实这里就是报FILE$与数据文件头中的SCN都增加了，并且修改为一样的时候，解决问题 |
上面就是数据文件头损坏的修复方法。
下面是ASM磁盘头的部分ASM DATA DISK1 ASM DATA DISK1 ASM ARCH DISK1kfbh.endian: 1 ; 0x000: 0x01 1 1 ; kfbh.hard: 130 ; 0x001: 0x82 130 130 ; kfbh.type: 1 ; 0x002: KFBTYP_DISKHEAD 1 1 ; kfbh.datfmt: 1 ; 0x003: 0x01 1 1 ; kfbh.block.blk: 0 ; 0x004: T=0 NUMB=0x0 0 0 ; kfbh.block.obj: 2147483648 ; 0x008: TYPE=0x8 NUMB=0x0 2147483649 2147483648 ; kfbh.check: 2196044811 ; 0x00c: 0x82e4fc0b 2196041737 1363709710 ; kfbh.fcn.base: 0 ; 0x010: 0x00000000 0 0 ; kfbh.fcn.wrap: 0 ; 0x014: 0x00000000 0 0 ; kfbh.spare1: 0 ; 0x018: 0x00000000 0 0 ; kfbh.spare2: 0 ; 0x01c: 0x00000000 0 0 ; kfdhdb.driver.provstr: ORCLDISK ; 0x000: length=8 ORCLDISK ORCLDISK ; kfdhdb.driver.reserved[0]: 0 ; 0x008: 0x00000000 0 0 ; kfdhdb.driver.reserved
: 0 ; 0x00c: 0x00000000 0 0 ; kfdhdb.driver.reserved 
: 0 ; 0x010: 0x00000000 0 0 ; kfdhdb.driver.reserved 
: 0 ; 0x014: 0x00000000 0 0 ; kfdhdb.driver.reserved 
: 0 ; 0x018: 0x00000000 0 0 ; kfdhdb.driver.reserved 
: 0 ; 0x01c: 0x00000000 0 0 ; kfdhdb.compat: 168820736 ; 0x020: 0x0a100000 168820736 168820736 ; kfdhdb.dsknum: 0 ; 0x024: 0x0000 1 0 ; kfdhdb.grptyp: 1 ; 0x026: KFDGTP_EXTERNAL 1 1 ; kfdhdb.hdrsts: 3 ; 0x027: KFDHDR_MEMBER 3 3 ; kfdhdb.dskname: DATA_0000 ; 0x028: length=9 DATA_0001 ARCH_0000 ; kfdhdb.grpname: DATA ; 0x048: length=4 DATA ARCH ; kfdhdb.fgname: DATA_0000 ; 0x068: length=9 DATA_0001 ARCH_0000 ; kfdhdb.capname: ; 0x088: length=0 ; kfdhdb.crestmp.hi: 32990918 ; 0x0a8: HOUR=0x6 DAYS=0x16 MNTH=0x9 YEAR=0x7dd 32990918 32990918 ; kfdhdb.crestmp.lo: 1457410048 ; 0x0ac: USEC=0x0 MSEC=0x394 SECS=0x2d MINS=0x15 1457410048 2373730304 ; kfdhdb.mntstmp.hi: 32990918 ; 0x0b0: HOUR=0x6 DAYS=0x16 MNTH=0x9 YEAR=0x7dd 32990918 32990918 ; kfdhdb.mntstmp.lo: 1464157184 ; 0x0b4: USEC=0x0 MSEC=0x151 SECS=0x34 MINS=0x15 1464157184 2381979648 ; kfdhdb.secsize: 512 ; 0x0b8: 0x0200 512 512 ; kfdhdb.blksize: 4096 ; 0x0ba: 0x1000 4096 4096 ; kfdhdb.ausize: 1048576 ; 0x0bc: 0x00100000 1048576 1048576 ; kfdhdb.mfact: 113792 ; 0x0c0: 0x0001bc80 113792 113792 ; kfdhdb.dsksize: 1024 ; 0x0c4: 0x00000400 2048 3072 ; kfdhdb.pmcnt: 2 ; 0x0c8: 0x00000002 2 2 ; kfdhdb.fstlocn: 1 ; 0x0cc: 0x00000001 1 1 ; kfdhdb.altlocn: 2 ; 0x0d0: 0x00000002 2 2 ; kfdhdb.f1b1locn: 2 ; 0x0d4: 0x00000002 0 2 ; kfdhdb.redomirrors[0]: 0 ; 0x0d8: 0x0000 0 0 ; kfdhdb.redomirrors 
: 0 ; 0x0da: 0x0000 0 0 ; kfdhdb.redomirrors 
: 0 ; 0x0dc: 0x0000 0 0 ; kfdhdb.redomirrors 
: 0 ; 0x0de: 0x0000 0 0 ; kfdhdb.dbcompat: 168820736 ; 0x0e0: 0x0a100000 168820736 168820736 ; kfdhdb.grpstmp.hi: 32990918 ; 0x0e4: HOUR=0x6 DAYS=0x16 MNTH=0x9 YEAR=0x7dd 32990918 32990918 ; kfdhdb.grpstmp.lo: 1457384448 ; 0x0e8: USEC=0x0 MSEC=0x37b SECS=0x2d MINS=0x15 1457384448 2373709824 ; kfdhdb.ub4spare[0]: 0 ; 0x0ec: 0x00000000 0 0 ; kfdhdb.ub4spare 
: 0 ; 0x0f0: 0x00000000 0 0 ; kfdhdb.ub4spare 
: 0 ; 0x0f4: 0x00000000 0 0 ; kfdhdb.ub4spare 
: 0 ; 0x0f8: 0x00000000 0 0 ; kfdhdb.ub4spare 
: 0 ; 0x0fc: 0x00000000 0 0 ; kfdhdb.ub4spare 
: 0 ; 0x100: 0x00000000 0 0 ; kfdhdb.ub4spare 
: 0 ; 0x104: 0x00000000 0 0 ; kfdhdb.ub4spare 
: 0 ; 0x108: 0x00000000 0 0 ; kfdhdb.ub4spare 
: 0 ; 0x10c: 0x00000000 0 0 ; kfdhdb.ub4spare 
: 0 ; 0x110: 0x00000000 0 0 ; kfdhdb.ub4spare[10]: 0 ; 0x114: 0x00000000 0 0 ; kfdhdb.ub4spare[11]: 0 ; 0x118: 0x00000000 0 0 ; kfdhdb.ub4spare[12]: 0 ; 0x11c: 0x00000000 0 0 ; kfdhdb.ub4spare[13]: 0 ; 0x120: 0x00000000 0 0 ; kfdhdb.ub4spare[14]: 0 ; 0x124: 0x00000000 0 0 ; kfdhdb.ub4spare[15]: 0 ; 0x128: 0x00000000 0 0 ; kfdhdb.ub4spare[16]: 0 ; 0x12c: 0x00000000 0 0 ; kfdhdb.ub4spare[17]: 0 ; 0x130: 0x00000000 0 0 ; kfdhdb.ub4spare[18]: 0 ; 0x134: 0x00000000 0 0 ; kfdhdb.ub4spare[19]: 0 ; 0x138: 0x00000000 0 0 ; kfdhdb.ub4spare[20]: 0 ; 0x13c: 0x00000000 0 0 ; kfdhdb.ub4spare[21]: 0 ; 0x140: 0x00000000 0 0 ; kfdhdb.ub4spare 
: 0 ; 0x144: 0x00000000 0 0 ; kfdhdb.ub4spare[23]: 0 ; 0x148: 0x00000000 0 0 ; kfdhdb.ub4spare[24]: 0 ; 0x14c: 0x00000000 0 0 ; kfdhdb.ub4spare[25]: 0 ; 0x150: 0x00000000 0 0 ; kfdhdb.ub4spare[26]: 0 ; 0x154: 0x00000000 0 0 ; kfdhdb.ub4spare[27]: 0 ; 0x158: 0x00000000 0 0 ; kfdhdb.ub4spare[28]: 0 ; 0x15c: 0x00000000 0 0 ; kfdhdb.ub4spare[29]: 0 ; 0x160: 0x00000000 0 0 ; kfdhdb.ub4spare[30]: 0 ; 0x164: 0x00000000 0 0 ; kfdhdb.ub4spare[31]: 0 ; 0x168: 0x00000000 0 0 ; kfdhdb.ub4spare[32]: 0 ; 0x16c: 0x00000000 0 0 ; kfdhdb.ub4spare[33]: 0 ; 0x170: 0x00000000 0 0 ; kfdhdb.ub4spare[34]: 0 ; 0x174: 0x00000000 0 0 ; kfdhdb.ub4spare[35]: 0 ; 0x178: 0x00000000 0 0 ; kfdhdb.ub4spare[36]: 0 ; 0x17c: 0x00000000 0 0 ; kfdhdb.ub4spare[37]: 0 ; 0x180: 0x00000000 0 0 ; kfdhdb.ub4spare[38]: 0 ; 0x184: 0x00000000 0 0 ; kfdhdb.ub4spare[39]: 0 ; 0x188: 0x00000000 0 0 ; kfdhdb.ub4spare[40]: 0 ; 0x18c: 0x00000000 0 0 ; kfdhdb.ub4spare[41]: 0 ; 0x190: 0x00000000 0 0 ; kfdhdb.ub4spare[42]: 0 ; 0x194: 0x00000000 0 0 ; kfdhdb.ub4spare[43]: 0 ; 0x198: 0x00000000 0 0 ; kfdhdb.ub4spare[44]: 0 ; 0x19c: 0x00000000 0 0 ; kfdhdb.ub4spare[45]: 0 ; 0x1a0: 0x00000000 0 0 ; kfdhdb.ub4spare[46]: 0 ; 0x1a4: 0x00000000 0 0 ; kfdhdb.ub4spare[47]: 0 ; 0x1a8: 0x00000000 0 0 ; kfdhdb.ub4spare[48]: 0 ; 0x1ac: 0x00000000 0 0 ; kfdhdb.ub4spare[49]: 0 ; 0x1b0: 0x00000000 0 0 ; kfdhdb.ub4spare[50]: 0 ; 0x1b4: 0x00000000 0 0 ; kfdhdb.ub4spare[51]: 0 ; 0x1b8: 0x00000000 0 0 ; kfdhdb.ub4spare[52]: 0 ; 0x1bc: 0x00000000 0 0 ; kfdhdb.ub4spare[53]: 0 ; 0x1c0: 0x00000000 0 0 ; kfdhdb.ub4spare[54]: 0 ; 0x1c4: 0x00000000 0 0 ; kfdhdb.ub4spare[55]: 0 ; 0x1c8: 0x00000000 0 0 ; kfdhdb.ub4spare[56]: 0 ; 0x1cc: 0x00000000 0 0 ; kfdhdb.ub4spare[57]: 0 ; 0x1d0: 0x00000000 0 0 ; kfdhdb.acdb.aba.seq: 0 ; 0x1d4: 0x00000000 0 0 ; kfdhdb.acdb.aba.blk: 0 ; 0x1d8: 0x00000000 0 0 ; kfdhdb.acdb.ents: 0 ; 0x1dc: 0x0000 0 0 ; kfdhdb.acdb.ub2spare: 0 ; 0x1de: 0x0000 0 0 ;