ORA-01210: data file header is media corrupt

  • 问题现象
  • 模拟过程
    • 加盘 创建lv
    • raw映射
    • 在raw上面创建表空间
    • 模拟报错
  • 解决方案
    • bbed探索数据文件结构
    • dump
  • 解决
  • 拓展
    • 确定redo的sequence#
    • controlfile
  • 总结

在现网环境中，启动数据库的时候，出现了报错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           02  /u01/app/oracle/oradata/ZHUO/datafile/o1_mf_sysaux_gxd20k1           03  /u01/app/oracle/oradata/ZHUO/datafile/o1_mf_undotbs1_gxd20           04  /u01/app/oracle/oradata/ZHUO/datafile/o1_mf_users_gxd20pxk           05  /u01/app/oracle/oradata/ZHUO/datafile/o1_mf_zhuo_gxdcfr5s_           0

BBED> set file 1 block 1
FILE# 1
BLOCK# 1

BBED> map /vFile: /u01/app/oracle/oradata/ZHUO/datafile/o1_mf_system_gxd20h14_.dbf (1)Block: 1                                     Dba:0x00400001
------------------------------------------------------------Data File Headerstruct 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+142          1         53   52428800        512          1 NO  INACTIVE                753214 21-NOV-19          773255 31-JUL-203          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
通过上面的标志位，就可以区分哪些是数据文件，哪些是日志文件，哪些是控制文件。

ORA-01210: data file header is media corrupt相关推荐

  1. R：CSV读取问题Error in read.table(file = file, header = header, sep = sep, quote = quote, : 列的数目比列的名字要多

    Error in read.table(file = file, header = header, sep = sep, quote = quote, : 列的数目比列的名字要多 Code: user ...

  2. ORA-01157 cannot identify/lock data file n 故障一例

    分享一下我老师大神的人工智能教程!零基础,通俗易懂!http://blog.csdn.net/jiangjunshow 也欢迎大家转载本篇文章.分享知识,造福人民,实现我们中华民族伟大复兴! 最近在使 ...

  3. ORA-01157: cannot identify/lock data file n 故障一例

    最近在使用swingbench的时候碰到了ORA-01157故障,下面是其具体描述与解决. 1.故障现象 --查询视图dba_data_files时出现ORA-01157故障 SQL> sele ...

  4. oracle ORA-01113的解决方法（file 1 needs media recovery）

    oracle ORA-01113的解决方法(file 1 needs media recovery) 参考文章: (1)oracle ORA-01113的解决方法(file 1 needs media ...

  5. oracle dbwr trace文件,ORA-01157: cannot identify/lock data file 19 - see DBWR trace file问题处理...

    ORA-01157: cannot identify/lock data file 19 - see DBWR trace file问题处理 告警信息: ORA-01157: cannot ident ...

  6. ORA-01157: cannot identify/lock data file处理

    ERROR 2010-12-09 09:24:06,281 OracleProcedure:callProcedure - 执行存储过程:pr_test 失败,原因:ORA-01157: cannot ...

  7. Error opening data file Tesseract-OCR\tessdata/eng.traineddata问题解决

    Error opening data file Tesseract-OCR\tessdata/eng.traineddata问题解决 在安装完tesseract, pytesseract后执行测试命令 ...

  8. 【Oracle】ORA-01157: cannot identify/lock data file 201 - see DBWR trace file

    今天数据库在查询数据的时候显示了这个错误: ORA-01157: cannot identify/lock data file 201 - see DBWR trace file ORA-01110: ...

  9. InnoDB: auto-extending data file ./ibdata1 is of a different size 0 pages (rounded down to MB) than

    报错详情 [mysql@infoplat5-zww:~]$/usr/local/mysql/scripts/mysql_install_db --user=mysql --basedir=/usr/l ...

最新文章

  1. 讲讲Git如何合并分支（一）
  2. golang 比较字符串 版本号大小
  3. Java多线程闲聊（一）：概论
  4. Metal之Shading Language Specification(着色语言规范)
  5. iOS Hacker Xcode7免登录开发者账号打包ipa
  6. 在c语言中i10是什么意思啊,2011年计算机二级考试C语言十套上机题
  7. Photoshop的基本操作
  8. play!框架_在Play上使用twitter4j！ 框架和安全社交很容易
  9. 《spring-boot学习》-11-定时任务
  10. 【SSH进阶】No result defined for action **的解决方案
  11. ubuntu安装mysql_如何在Ubuntu14.04中安装mysql
  12. 【专家访谈】测试专家 - 陈林钧，访谈问题收集中
  13. keepalived实现双机互备
  14. Kafka权威指南 —— 读书笔记
  15. 【从零开始学TVM】三，基于ONNX模型结构了解TVM的前端
  16. django mysql sql语句_Django笔记：连接数据库并执行SQL语句
  17. 自然语言处理和编译器的对比
  18. win10 安装 ad9
  19. vue中使用keep-alive无效以及include 和 exclude用法
  20. SQL Server 数据库常用操作：修改数据（ALTER、UPDATE语句的使用）

热门文章

  1. Python软件编程等级考试三级——20210314
  2. 游戏美术设计从业者过了30岁后都是如何发展的？
  3. java soap附件_java – 没有附件的SOAPMessage writeTo
  4. chmod 755和chmod +x 区别 | Linux修改文件属性 | 小白笔记
  5. iOS动画——文字晃动
  6. 四种物联网卡计算模式
  7. 关于五常膝关节矫形器的介绍
  8. 五部搞定Android开发环境部署——费UC噶不过详细的Android开发环境搭建教程
  9. 以太坊智能合约solidity去中心化投票系统
  10. 什么是G.654E光纤？