ORA-01210: data file header is media corrupt
在现网环境中,启动数据库的时候,出现了报错ORA-01210: data file header is media corrupt。刚开始以为是datafile header块头坏了。但是经过bbed校验后,发现都是正确的文件格式。所以,我们考虑了另一种情况,是不是磁盘绑定,绑错位了。所以下面就是我们模拟该问题,并提供解决思路。当出现ORA-01210情况的时候,不一定就是数据文件头块坏了,还有其他的可能性。下面就是具体的模拟并解决过程。
问题现象
SQL> alter database open;
alter database open
*
ERROR at line 1:
ORA-01122: database file 6 failed verification check
ORA-01110: data file 6: ‘/dev/raw/raw1’
ORA-01210: data file header is media corrupt
模拟过程
说明下:现网环境用的还是raw,所以以下就以raw方式模拟
加盘 创建lv
[root@oracle11g ~]# pvcreate /dev/sdb
Physical volume “/dev/sdb” successfully created
[root@oracle11g ~]# vgcreate vg_app /dev/sdb
Volume group “vg_app” successfully created
[root@oracle11g ~]# lvcreate -L 50M -n lv_wahaha1 vg_app
Rounding up size to full physical extent 52.00 MiB
Logical volume “lv_wahaha1” created.
[root@oracle11g ~]# lvcreate -L 48m -n lv_wahaha2 vg_app
Logical volume “lv_wahaha2” created.
[root@oracle11g ~]# lvs
LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert
lv_wahaha1 vg_app -wi-a----- 52.00m
lv_wahaha2 vg_app -wi-a----- 48.00m
lv_root vg_system -wi-ao---- 47.80g
lv_swap vg_system -wi-ao---- 2.00g
[root@oracle11g ~]# vgs
VG #PV #LV #SN Attr VSize VFree
vg_app 1 2 0 wz–n- 100.00m 0
vg_system 1 2 0 wz–n- 49.80g 0
raw映射
[root@oracle11g ~]# raw /dev/raw/raw1 /dev/mapper/vg_app-lv_wahaha1
/dev/raw/raw1: bound to major 253, minor 2
[root@oracle11g ~]# raw /dev/raw/raw2 /dev/mapper/vg_app-lv_wahaha2
/dev/raw/raw2: bound to major 253, minor 3
查看raw的信息:
[root@oracle11g ~]# raw -qa
/dev/raw/raw1: bound to major 253, minor 2
/dev/raw/raw2: bound to major 253, minor 3
查看本机设备
[root@oracle11g ~]# ls -ltr /dev/mapper/vg_*
lrwxrwxrwx. 1 root root 7 Jul 31 14:55 /dev/mapper/vg_system-lv_swap -> …/dm-1
lrwxrwxrwx. 1 root root 7 Jul 31 14:55 /dev/mapper/vg_system-lv_root -> …/dm-0
lrwxrwxrwx. 1 root root 7 Jul 31 15:00 /dev/mapper/vg_app-lv_wahaha1 -> …/dm-2
lrwxrwxrwx. 1 root root 7 Jul 31 15:02 /dev/mapper/vg_app-lv_wahaha2 -> …/dm-3
[root@oracle11g ~]# ls -ltr /dev/dm-*
brw-rw----. 1 root disk 253, 1 Jul 31 14:55 /dev/dm-1
brw-rw----. 1 root disk 253, 0 Jul 31 14:55 /dev/dm-0
brw-rw----. 1 root disk 253, 2 Jul 31 15:00 /dev/dm-2
brw-rw----. 1 root disk 253, 3 Jul 31 15:02 /dev/dm-3
[root@oracle11g datafile]# ll /dev/raw/raw*
crw-rw----. 1 root disk 162, 1 Jul 31 15:11 /dev/raw/raw1
crw-rw----. 1 root disk 162, 2 Jul 31 15:11 /dev/raw/raw2
crw-rw----. 1 root disk 162, 0 Jul 31 14:55 /dev/raw/rawctl
修改raw权限
[root@oracle11g datafile]# chown oracle:oinstall /dev/raw/raw1
[root@oracle11g datafile]# chown oracle:oinstall /dev/raw/raw2
[root@oracle11g datafile]# ll /dev/raw/raw*
crw-rw----. 1 oracle oinstall 162, 1 Jul 31 15:21 /dev/raw/raw1
crw-rw----. 1 oracle oinstall 162, 2 Jul 31 15:11 /dev/raw/raw2
crw-rw----. 1 root disk 162, 0 Jul 31 14:55 /dev/raw/rawctl
在raw上面创建表空间
SQL> create tablespace tbs1 datafile ‘/dev/raw/raw1’ size 20M;
Tablespace created.
SQL> create tablespace tbs2 datafile ‘/dev/raw/raw2’ size 20M;
Tablespace created.
SQL> create table wahaha tablespace tbs1 as select * from dba_users;
Table created.
SQL> select name,file# from v$datafile;
SQL> set pages 1000 lines 1000
SQL> col name for a100
NAME FILE#
/u01/app/oracle/oradata/ZHUO/datafile/o1_mf_system_gxd20h14_.dbf 1
/u01/app/oracle/oradata/ZHUO/datafile/o1_mf_sysaux_gxd20k1y_.dbf 2
/u01/app/oracle/oradata/ZHUO/datafile/o1_mf_undotbs1_gxd20lnp_.dbf 3
/u01/app/oracle/oradata/ZHUO/datafile/o1_mf_users_gxd20pxk_.dbf 4
/u01/app/oracle/oradata/ZHUO/datafile/o1_mf_zhuo_gxdcfr5s_.dbf 5
/dev/raw/raw1 6
/dev/raw/raw2 7
7 rows selected.
模拟报错
模拟主机异常宕机
[root@oracle11g ~]# reboot
重新启动数据库
SQL> startup
ORACLE instance started.
Total System Global Area 521936896 bytes
Fixed Size 2254824 bytes
Variable Size 352323608 bytes
Database Buffers 163577856 bytes
Redo Buffers 3780608 bytes
Database mounted.
ORA-01157: cannot identify/lock data file 6 - see DBWR trace file
ORA-01110: data file 6: ‘/dev/raw/raw1’
发现raw没有映射,手动重新映射。(这里模拟我们不知道lv和raw之间的对应关系,我们手动映射错了)
[root@oracle11g ~]# chown oracle:oinstall /dev/raw/raw1
[root@oracle11g ~]# chown oracle:oinstall /dev/raw/raw2
[root@oracle11g ~]# ls -tlr /dev/raw/*
crw-rw----. 1 root disk 162, 0 Jul 31 15:24 /dev/raw/rawctl
crw-rw----. 1 oracle oinstall 162, 1 Jul 31 15:38 /dev/raw/raw1
crw-rw----. 1 oracle oinstall 162, 2 Jul 31 15:38 /dev/raw/raw2
重启数据库
[oracle@oracle11g ~]$ sqlplus / as sysdba
SQL*Plus: Release 11.2.0.4.0 Production on Fri Jul 31 15:39:09 2020
Copyright © 1982, 2013, Oracle. All rights reserved.
Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
SQL> alter database open;
alter database open
*
ERROR at line 1:
ORA-01122: database file 6 failed verification check
ORA-01110: data file 6: ‘/dev/raw/raw1’
ORA-01210: data file header is media corrupt
启动数据库报错:ORA-01210。
解决方案
既然是lv的对应关系绑定错位了,那就要知道正确的对应关系。
下面查看现在的绑定对应关系(由于我的是虚拟机,所以major和minor号,没在lv上面显示,在具体的磁盘上面显示)
[root@oracle11g ~]# raw -qa
/dev/raw/raw1: bound to major 253, minor 3
/dev/raw/raw2: bound to major 253, minor 2
[root@oracle11g ~]# ls -ltr /dev/raw/raw*
crw-rw----. 1 root disk 162, 0 Jul 31 15:24 /dev/raw/rawctl
crw-rw----. 1 oracle oinstall 162, 1 Jul 31 15:38 /dev/raw/raw1
crw-rw----. 1 oracle oinstall 162, 2 Jul 31 15:38 /dev/raw/raw2
[root@oracle11g ~]# ls -ltr /dev/mapper/
total 0
crw-rw----. 1 root root 10, 58 Jul 31 15:24 control
lrwxrwxrwx. 1 root root 7 Jul 31 15:24 vg_system-lv_swap -> …/dm-1
lrwxrwxrwx. 1 root root 7 Jul 31 15:24 vg_app-lv_wahaha2 -> …/dm-3
lrwxrwxrwx. 1 root root 7 Jul 31 15:24 vg_app-lv_wahaha1 -> …/dm-2
lrwxrwxrwx. 1 root root 7 Jul 31 15:24 vg_system-lv_root -> …/dm-0
[root@oracle11g ~]# ls -ltr /dev/dm*
brw-rw----. 1 root disk 253, 1 Jul 31 15:24 /dev/dm-1
brw-rw----. 1 root disk 253, 3 Jul 31 15:24 /dev/dm-3
brw-rw----. 1 root disk 253, 2 Jul 31 15:24 /dev/dm-2
brw-rw----. 1 root disk 253, 0 Jul 31 15:24 /dev/dm-0
现在虽然知道file# 6对应着/dev/raw/raw1;file# 7对应/dev/raw/raw2;(从v$datafile.name可以看出对应关系)。但是底层的设备绑定对应关系却是不知道的,即不知道/dev/raw/raw1绑定的vg_app-lv_wahaha2还是vg_app-lv_wahaha1.
有一种方法,因为datafile是存储在存储设备上的,真实存储在磁盘上面的内容是不会混乱的,我们可以直接查看设备上面存储的内容,来判断对应关系。
那么就需要我们知道这个设备上面存储的是file#为多少的文件。所以要定位这个数据文件datafile是几号文件。
所以问题的关键就变为了,存储设备上存储的数据文件的几号文件了,所以以下就是确定存储设备上面的file number了,下面演示集中方法:
bbed探索数据文件结构
如果我们知道数据文件的结构,那么很容易定位file#的位置,但datafile的结构比较复杂,其实file#在 datafile的头块中就有,所以下面我们只看datafile header block
BBED> info all
File# Name Size(blks)
1 /u01/app/oracle/oradata/ZHUO/datafile/o1_mf_system_gxd20h1 0
2 /u01/app/oracle/oradata/ZHUO/datafile/o1_mf_sysaux_gxd20k1 0
3 /u01/app/oracle/oradata/ZHUO/datafile/o1_mf_undotbs1_gxd20 0
4 /u01/app/oracle/oradata/ZHUO/datafile/o1_mf_users_gxd20pxk 0
5 /u01/app/oracle/oradata/ZHUO/datafile/o1_mf_zhuo_gxdcfr5s_ 0
BBED> set file 1 block 1
FILE# 1
BLOCK# 1
BBED> map /v
File: /u01/app/oracle/oradata/ZHUO/datafile/o1_mf_system_gxd20h14_.dbf (1)
Block: 1 Dba:0x00400001
------------------------------------------------------------
Data File Header
struct kcvfh, 860 bytes @0
struct kcvfhbfh, 20 bytes @0
struct kcvfhhdr, 76 bytes @20
ub4 kcvfhrdb @96
struct kcvfhcrs, 8 bytes @100
ub4 kcvfhcrt @108
ub4 kcvfhrlc @112
struct kcvfhrls, 8 bytes @116
ub4 kcvfhbti @124
struct kcvfhbsc, 8 bytes @128
ub2 kcvfhbth @136
ub2 kcvfhsta @138
struct kcvfhckp, 36 bytes @484
ub4 kcvfhcpc @140
ub4 kcvfhrts @144
ub4 kcvfhccc @148
struct kcvfhbcp, 36 bytes @152
ub4 kcvfhbhz @312
struct kcvfhxcd, 16 bytes @316
sword kcvfhtsn @332
ub2 kcvfhtln @336
text kcvfhtnm[30] @338
ub4 kcvfhrfn @368
struct kcvfhrfs, 8 bytes @372
ub4 kcvfhrft @380
struct kcvfhafs, 8 bytes @384
ub4 kcvfhbbc @392
ub4 kcvfhncb @396
ub4 kcvfhmcb @400
ub4 kcvfhlcb @404
ub4 kcvfhbcs @408
ub2 kcvfhofb @412
ub2 kcvfhnfb @414
ub4 kcvfhprc @416
struct kcvfhprs, 8 bytes @420
struct kcvfhprfs, 8 bytes @428
ub4 kcvfhtrt @444
ub4 tailchk @8188
BBED> p kcvfhhdr
struct kcvfhhdr, 76 bytes @20
ub4 kccfhswv @20 0x00000000
ub4 kccfhcvn @24 0x0b200400
ub4 kccfhdbi @28 0xed5cfdce
text kccfhdbn[0] @32 Z
text kccfhdbn[1] @33 H
text kccfhdbn[2] @34 U
text kccfhdbn[3] @35 O
text kccfhdbn[4] @36
text kccfhdbn[5] @37
text kccfhdbn[6] @38
text kccfhdbn[7] @39
ub4 kccfhcsq @40 0x000002de
ub4 kccfhfsz @44 0x00015e00
s_blkz kccfhbsz @48 0x00
ub2 kccfhfno @52 0x0001 —file#
ub2 kccfhtyp @54 0x0003
ub4 kccfhacid @56 0x00000000
ub4 kccfhcks @60 0x00000000
text kccfhtag[0] @64
text kccfhtag[1] @65
text kccfhtag[2] @66
text kccfhtag[3] @67
text kccfhtag[4] @68
text kccfhtag[5] @69
text kccfhtag[6] @70
text kccfhtag[7] @71
text kccfhtag[8] @72
text kccfhtag[9] @73
text kccfhtag[10] @74
text kccfhtag[11] @75
text kccfhtag[12] @76
text kccfhtag[13] @77
text kccfhtag[14] @78
text kccfhtag[15] @79
text kccfhtag[16] @80
text kccfhtag[17] @81
text kccfhtag[18] @82
text kccfhtag[19] @83
text kccfhtag[20] @84
text kccfhtag[21] @85
text kccfhtag[22] @86
text kccfhtag[23] @87
text kccfhtag[24] @88
text kccfhtag[25] @89
text kccfhtag[26] @90
text kccfhtag[27] @91
text kccfhtag[28] @92
text kccfhtag[29] @93
text kccfhtag[30] @94
text kccfhtag[31] @95
其他的结构,我们在用到的时候在剖析。在上面的内容中offset 52就为fileno#,文件号,长度为2个字节(offset 54-52=2字节)。
那么下面的工作就简单了,只要读取offset52的内容就可以了,bbed dump可以,dd也可以,ue也可以。(注意,在以前的文章中提到过,dd是正常的字节序,dd dump和ue读取出来的字节序都是反的)。
下面使用dd来读取(因为一般的环境中没有bbed)
我们可以使用dd工具直接读取数据文件,读取offset 52的位置,如下:
[root@oracle11g ~]# dd if=/dev/dm-2 skip=1 bs=8192 count=1|od -x
1+0 records in
1+0 records out
8192 bytes (8.2 kB) copied, 0.000404886 s, 20.2 MB/s
0000000 a20b 0000 0001 0180 0000 0000 0000 0401
0000020 d8ee 0000 0000 0000 0400 0b20 fdce ed5c
0000040 485a 4f55 0000 0000 02d3 0000 0a00 0000
0000060 2000 0000 0006 0003 0000 0000 0000 0000 ----offset52-53:值为0006
0000100 0000 0000 0000 0000 0000 0000 0000 0000
*
0000140 0000 0000 d820 000b 0000 0000 5bef 3e6b
0000160 060e 3d17 0001 0000 0000 0000 0000 0000
0000200 0000 0000 0000 0000 0000 0004 0002 0000
0000220 0000 0000 0001 0000 0000 0000 0000 0000
0000240 0000 0000 0000 0000 0000 0000 0000 0000
*
0000500 0000 0000 0000 0000 0000 0000 0006 0000
0000520 0004 4254 3153 0000 0000 0000 0000 0000
0000540 0000 0000 0000 0000 0000 0000 0000 0000
0000560 0006 0000 0000 0000 0000 0000 0000 0000
0000600 0000 0000 0000 0000 0000 0000 0000 0000
*
0000740 0000 0000 d821 000b 0000 0000 5bef 3e6b
0000760 0001 0000 0036 0000 0db9 0000 0010 0000
0001000 0002 0000 0000 0000 0000 0000 0000 0000
0001020 0000 0000 0000 0000 0000 0000 0000 0000
*
0001200 0000 0000 000d 000d 000d 0001 0000 0000
0001220 0000 0000 0000 0000 0002 0180 0000 0000
0001240 0000 0000 0000 0000 0000 0000 0000 0000
*
0017760 0
这是常规写法,此处再写几种以前没尝试过的:
[root@oracle11g ~]# dd if=/dev/dm-2 skip=8244 bs=1 count=2|od -x
2+0 records in
2+0 records out
2 bytes (2 B) copied, 0.000218039 s, 9.2 kB/s
0000000 0006
0000002
[root@oracle11g ~]# dd if=/dev/dm-2 skip=8244 bs=1 count=2|od -d
2+0 records in
2+0 records out
2 bytes (2 B) copied, 0.000357934 s, 5.6 kB/s
0000000 6
0000002
[root@oracle11g ~]# dd if=/dev/dm-3 skip=8244 bs=1 count=2|od -d
2+0 records in
2+0 records out
2 bytes (2 B) copied, 0.000375913 s, 5.3 kB/s
0000000 7
0000002
说明,offset和block都是从0开始。所以skip=8192+52=8244,即跳过了52字节,从53字节处开始,因为offset从0开始,所以dump的也就是52字节出的内容。
count=2*1.只dump2个字节。
即/dev/dm-2上面存储的是6号数据文件,/dev/dm-3上面存储的是7号数据文件.
dump
File Header
ALTER SESSION SET EVENTS ‘immediate trace name file_hdrs level n’;
1 控制文件中的文件头信息
2 level 1 + 文件头信息
3 level 2 + 数据文件头信息
10 level 3
SQL> oradebug setmypid
Statement processed.
SQL> alter session set events 'immediate trace name file_hdrs level 3';
Session altered.
SQL> oradebug tracefile_name;
/u01/app/oracle/diag/rdbms/zhuo/zhuo/trace/zhuo_ora_2763.tr
此处我们使用level 3,把控制文件和数据文件头的信息都dump出来,对比着看。
dump的片段
DATA FILE #6:
name #10: /dev/raw/raw1
creation size=2560 block size=8192 status=0xe head=10 tail=10 dup=1
tablespace 6, index=7 krfil=6 prev_file=0
unrecoverable scn: 0x0000.00000000 01/01/1988 00:00:00
Checkpoint cnt:2 scn: 0x0000.000bd821 07/31/2020 15:21:19
Stop scn: 0xffff.ffffffff 07/31/2020 15:21:19
Creation Checkpointed at scn: 0x0000.000bd820 07/31/2020 15:21:19
thread:1 rba:(0x36.db9.10)
enabled threads: 01000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 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
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
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
File header version cannot be determined due to Dump may be suspect
V10 STYLE FILE HEADER:
Compatibility Vsn = 186647552=0xb200400
Db ID=3982294478=0xed5cfdce, Db Name=‘ZHUO’
Activation ID=0=0x0
Control Seq=728=0x2d8, File size=2560=0xa00
File Number=7, Blksiz=8192, File Type=3 DATA
。。。。。。
DATA FILE #7:
name #11: /dev/raw/raw2
creation size=2560 block size=8192 status=0xe head=11 tail=11 dup=1
tablespace 7, index=8 krfil=7 prev_file=0
unrecoverable scn: 0x0000.00000000 01/01/1988 00:00:00
Checkpoint cnt:2 scn: 0x0000.000bd946 07/31/2020 15:22:04
Stop scn: 0xffff.ffffffff 07/31/2020 15:22:04
Creation Checkpointed at scn: 0x0000.000bd945 07/31/2020 15:22:04
thread:1 rba:(0x36.e64.10)
enabled threads: 01000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 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
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
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
File header version cannot be determined due to Dump may be suspect
V10 STYLE FILE HEADER:
Compatibility Vsn = 186647552=0xb200400
Db ID=3982294478=0xed5cfdce, Db Name=‘ZHUO’
Activation ID=0=0x0
Control Seq=723=0x2d3, File size=2560=0xa00
File Number=6, Blksiz=8192, File Type=3 DATA
以上dump分为两部分来看, Online move state: 0以上的为控制文件的内容,以下的为数据文件头部的内容。
我们可以看到,在控制文件中记录的对应关系没有变化,和视图v$datafile查询出来的信息一致,因为控制文件我们没有动。
而数据文件头部记录的内容和控制文件不一致,因为数据文件头部记录的是真实的datafile内容,所以以数据文件头部为准,从File Number可以看出,两个文件对应关系反了。即/dev/raw1上对应着7号数据文件,/dev/raw2上对应着6号数据文件.根据major和minor号的,就可以核对出正确的raw和lv对应关系
解决
解绑原来错误的raw对应关系
[root@oracle11g ~]# raw /dev/raw/raw2 0 0
/dev/raw/raw2: bound to major 0, minor 0
[root@oracle11g ~]# raw /dev/raw/raw1 0 0
/dev/raw/raw1: bound to major 0, minor 0
重新绑定正确的对应关系
[root@oracle11g ~]# raw /dev/raw/raw1 /dev/mapper/vg_app-lv_wahaha1
/dev/raw/raw1: bound to major 253, minor 2
[root@oracle11g ~]# raw /dev/raw/raw2 /dev/mapper/vg_app-lv_wahaha2
/dev/raw/raw2: bound to major 253, minor 3
修改权限
[root@oracle11g ~]# chown oracle:oinstall /dev/raw/raw1
[root@oracle11g ~]# chown oracle:oinstall /dev/raw/raw2
[root@oracle11g ~]# su - oracle
启动数据库:
[oracle@oracle11g ~]$ sqlplus / as sysdba
SQL*Plus: Release 11.2.0.4.0 Production on Fri Jul 31 20:20:27 2020
Copyright © 1982, 2013, Oracle. All rights reserved.
Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
SQL> alter database open;
Database altered.
拓展
确定redo的sequence#
redo日志中的唯一号是Seq#,所以我们可以使用查找Seq#号来对应绑定关系
1)bbed
bbed也可以查看修改结构,但是具体的结构还不是很清楚,后面再研究
BBED> set filename ‘/u01/app/oracle/oradata/ZHUO/onlinelog/o1_mf_2_gxd20gn6_.log’
FILENAME /u01/app/oracle/oradata/ZHUO/onlinelog/o1_mf_2_gxd20gn6_.log
BBED> map /v
File: /u01/app/oracle/oradata/ZHUO/onlinelog/o1_mf_2_gxd20gn6_.log (0)
Block: 1 Dba:0x00000000
Undo Segment Header
struct kcbh, 20 bytes @0
ub1 type_kcbh @0
ub1 frmt_kcbh @1
ub1 spare1_kcbh @2
ub1 spare2_kcbh @3
ub4 rdba_kcbh @4
ub4 bas_kcbh @8
ub2 wrp_kcbh @12
ub1 seq_kcbh @14
ub1 flg_kcbh @15
ub2 chkval_kcbh @16
ub2 spare3_kcbh @18
struct ktect, 44 bytes @20
ub4 ktectspare @20
sword ktecttsn @24
ub4 ktectobj @28
ub4 ktectnex @32
ub2 ktecttbe @36
ub4 ktectcex @40
ub4 ktectces @44
ub4 ktectcbk @48
struct ktectxid, 8 bytes @52
ub1 ktectlck @60
struct ktetb[1701996628], 13615973024 bytes @64
ub4 ktetbdba @64
ub4 ktetbnbk @68
struct ktuxc, 104 bytes @774
struct ktuxcscn, 8 bytes @774
struct ktuxcuba, 8 bytes @782
sb2 ktuxcflg @790
ub2 ktuxcseq @792
sb2 ktuxcnfb @794
ub4 ktuxcinc @798
sb2 ktuxcchd @802
sb2 ktuxcctl @804
ub2 ktuxcmgc @806
ub4 ktuxcopt @814
struct ktuxcfbp[5], 60 bytes @818
struct ktuxe[0], 0 bytes @878
ub4 ktuxexid @878
ub4 ktuxebrb @882
struct ktuxescn, 8 bytes @886
sb4 ktuxesta @894
ub1 ktuxecfl @895
sb2 ktuxeuel @896
ub4 tailchk @508
2)strings
[oracle@oracle11g onlinelog]$ strings o1_mf_1_gxd20glv_.log |grep Seq#
Thread 0001, Seq# 0000000055, SCN 0x0000000c2891-0xffffffffffff
[oracle@oracle11g onlinelog]$ strings o1_mf_2_gxd20gn6_.log |grep Seq#
Thread 0001, Seq# 0000000053, SCN 0x0000000b7e3e-0x0000000bcc87
^[[A[oracle@oracle11g onlinelog]$ strings o1_mf_3_hl853rs5_.log |grep Seq#
Thread 0001, Seq# 0000000000, SCN 0x0000000bcc87-0x0000000c2891
SQL> select * from v$log;
GROUP# THREAD# SEQUENCE# BYTES BLOCKSIZE MEMBERS ARC STATUS FIRST_CHANGE# FIRST_TIME NEXT_CHANGE# NEXT_TIME
---------- ---------- ---------- ---------- ---------- ---------- --- ---------------- ------------- ------------ ------------ ------------
1 1 55 52428800 512 1 NO CURRENT 796817 31-JUL-20 2.8147E+14
2 1 53 52428800 512 1 NO INACTIVE 753214 21-NOV-19 773255 31-JUL-20
3 1 0 52428800 512 1 NO UNUSED 773255 31-JUL-20 796817 31-JUL-20
对比上面2各结果,v$log.sequence#和strings出来的SEQ#是相同的,所以可以根据Seq#来查找对应关系
3)dump redo header
ALTER SESSION SET EVENTS ‘immediate trace name redohdr level n’;
1 控制文件中的redo log信息
2 level 1 + 文件头信息
3 level 2 + 日志文件头信息
10 level 3
SQL> oradebug setmypid
Statement processed.
SQL> alter session set events 'immediate trace name redohdr level 10';
Session altered.
SQL> oradebug tracefile_name;
/u01/app/oracle/diag/rdbms/zhuo/zhuo/trace/zhuo_ora_3242.trc
LOG FILE #1:
name #1: /u01/app/oracle/oradata/ZHUO/onlinelog/o1_mf_1_gxd20glv_.log
Thread 1 redo log links: forward: 2 backward: 0
siz: 0x19000 seq: 0x00000037 hws: 0x9 bsz: 512 nab: 0xffffffff flg: 0x8 dup: 1
Archive links: fwrd: 0 back: 0 Prev scn: 0x0000.000bcc87
Low scn: 0x0000.000c2891 07/31/2020 20:20:30
Next scn: 0xffff.ffffffff 01/01/1988 00:00:00
FILE HEADER:
Compatibility Vsn = 186647552=0xb200400
Db ID=3982294478=0xed5cfdce, Db Name=‘ZHUO’
Activation ID=3982326478=0xed5d7ace
Control Seq=780=0x30c, File size=102400=0x19000
File Number=1, Blksiz=512, File Type=2 LOG
Format ID is 2
redo log key is 976378f9bf6de1a62b6a0f9115336b
redo log key flag is 5
descrip:“Thread 0001, Seq# 0000000055, SCN 0x0000000c2891-0xffffffffffff”
thread: 1 nab: 0xffffffff seq: 0x00000037 hws: 0x9 eot: 1 dis: 0
reset logs count: 0x3d17060e scn: 0x0000.00000001
Low scn: 0x0000.000c2891 07/31/2020 20:20:30
Next scn: 0xffff.ffffffff 01/01/1988 00:00:00
Enabled scn: 0x0000.00000001 11/21/2019 11:44:14
Thread closed scn: 0x0000.000c308b 07/31/2020 20:52:55
Disk cksum: 0x2911 Calc cksum: 0x2911
Terminal Recovery Stop scn: 0x0000.00000000
Terminal Recovery Stamp 01/01/1988 00:00:00
Most recent redo scn: 0x0000.00000000
Largest LWN: 0 blocks
Miscellaneous flags: 0x800000
Thread internal enable indicator: thr: 0, seq: 0 scn: 0x0000.00000000
Zero blocks: 0
Enabled redo threads: 1
以上的信息也分为2不分来看, **FILE HEADER:**以上为控制文件中的内容,以下的为redo文件头的信息。从关键字 seq: 0x00000037可以用来对应seq信息。
controlfile
文件号先后没关系,多路复用的内容都相同
总结
1)datafile file#的确认:
dd if=/dev/dm-3 skip=8244 bs=1 count=2|od -d
–注意替换文件路径
2)controlfile的确认。无所谓。
3)redo file#的确认
strings o1_mf_1_gxd20glv_.log |grep Seq#
–注意替换文件路径
4)各类文件的标志位
[oracle@oracle11g datafile]$ for ff in /u01/app/oracle/oradata/ZHUO/datafile/*
> do
> dd if=$ff bs=1 count=1 skip=1 2>/dev/null|od -x|head -1|awk -vFILE=$ff '{print FILE": "$2}'
> done
/u01/app/oracle/oradata/ZHUO/datafile/o1_mf_sysaux_gxd20k1y_.dbf: 00a2
/u01/app/oracle/oradata/ZHUO/datafile/o1_mf_system_gxd20h14_.dbf: 00a2
/u01/app/oracle/oradata/ZHUO/datafile/o1_mf_temp_gxd20m6o_.tmp: 00a2
/u01/app/oracle/oradata/ZHUO/datafile/o1_mf_undotbs1_gxd20lnp_.dbf: 00a2
/u01/app/oracle/oradata/ZHUO/datafile/o1_mf_users_gxd20pxk_.dbf: 00a2
/u01/app/oracle/oradata/ZHUO/datafile/o1_mf_zhuo_gxdcfr5s_.dbf: 00a2
[oracle@oracle11g datafile]$ for ff in /u01/app/oracle/oradata/ZHUO/onlinelog/*
> do
> dd if=$ff bs=1 count=1 skip=1 2>/dev/null|od -x|head -1|awk -vFILE=$ff '{print FILE": "$2}'
> done
/u01/app/oracle/oradata/ZHUO/onlinelog/o1_mf_1_gxd20glv_.log: 0022
/u01/app/oracle/oradata/ZHUO/onlinelog/o1_mf_2_gxd20gn6_.log: 0022
/u01/app/oracle/oradata/ZHUO/onlinelog/o1_mf_3_gxd20gq0_.log: 0022
[oracle@oracle11g datafile]$ for ff in /u01/app/oracle/oradata/ZHUO/controlfile/*
> do
> dd if=$ff bs=1 count=1 skip=1 2>/dev/null|od -x|head -1|awk -vFILE=$ff '{print FILE": "$2}'
> done
/u01/app/oracle/oradata/ZHUO/controlfile/o1_mf_gxd20gho_.ctl: 00c2
可以看出datafile、undo、temp都是:a2
redo都是:22
control file都是:c2
通过上面的标志位,就可以区分哪些是数据文件,哪些是日志文件,哪些是控制文件。