一种非常应用很广泛的架构：hacmp+rac+raw。这种架构采用裸设备作为数据文件。今天演示一种恢复场景：数据库异常宕机，数据文件顺序错乱，数据库无法启动。 下面通过实验逐步演示，如果把数据文件的正确顺序找出来： sql select * from v$version;banner----
一种非常应用很广泛的架构：hacmp+rac+raw。这种架构采用裸设备作为数据文件。今天演示一种恢复场景：数据库异常宕机，数据文件顺序错乱，数据库无法启动。
下面通过实验逐步演示，如果把数据文件的正确顺序找出来：
sql> select * from v$version;banner--------------------------------------------------------------------------------oracle database 11g enterprise edition release 11.2.0.4.0 - 64bit productionpl/sql release 11.2.0.4.0 - productioncore 11.2.0.4.0 productiontns for linux: version 11.2.0.4.0 - productionnlsrtl version 11.2.0.4.0 - production
展示表空间、数据文件的简要情况
sql> select ts#,name from v$tablespace;
ts# name
---------- --------------------
0 system
1 sysaux
2 undotbs1
3 temp
4 users
sql> select file#,name from v$datafile;
file# name
---------- ---------------------------------------------------------------------
1 /u01/app/oracle/oradata/primary/system01.dbf
2 /u01/app/oracle/oradata/primary/sysaux01.dbf
3 /u01/app/oracle/oradata/primary/undotbs01.dbf
4 /u01/app/oracle/oradata/primary/users01.dbf
“断电”式快速强制停库
sql> shutdown abort;
oracle instance shut down.
sql> startup mount;
oracle instance started.
total system global area 784998400 bytes
fixed size 2257352 bytes
variable size 700452408 bytes
database buffers 79691776 bytes
redo buffers 2596864 bytes
database mounted.
搞破坏，将system01.dbf和sysaux01.dbf两个数据文件相互替换名字
mv /u01/app/oracle/oradata/primary/system01.dbf /u01/app/oracle/oradata/primary/a
mv /u01/app/oracle/oradata/primary/sysaux01.dbf /u01/app/oracle/oradata/primary/system01.dbf
mv /u01/app/oracle/oradata/primary/a /u01/app/oracle/oradata/primary/sysaux01.dbf 
尝试启库，但会报错
sql> alter database open;
alter database open
*
error at line 1:
ora-01122: database file 1 failed verification check
ora-01110: data file 1: '/u01/app/oracle/oradata/primary/system01.dbf'
ora-01210: data file header is media corrupt
细心的朋友可能会顺便查询一下视图v$datafile_header
v$datafile是从控制文件里读取信息，而v$datafile_header是从数据文件头部读取信息。
其实到这里，已经能从file#,error,rfile#的值就可以看出，system01.dbf与sysaux01.dbf到换了，可以改名直接将数据库打开。我们不妨通过其他方法去修复破坏
以下已经提示system01.dbf数据文件头部损坏，我们dump部分数据文件瞧瞧：
dump数据文件头部
sql> alter system dump datafile '/u01/app/oracle/oradata/primary/system01.dbf' block 2;
system altered.
sql> alter system dump datafile '/u01/app/oracle/oradata/primary/sysaux01.dbf' block 2;
system altered.
以上可以看出,system01.dbf的头部记录着自身其实是2号数据文件
从以上可以看出,sysaux01.dbf头部记录着自身其实是1号数据文件
至此，可以判断，system01.dbf其实是sysaux表空间的数据文件，sysaux01.dbf其实是system的数据文件，对照v$datafile视图的输出将数据文件重命名:
重命名数据文件，修复破坏
mv /u01/app/oracle/oradata/primary/system01.dbf /u01/app/oracle/oradata/primary/b
mv /u01/app/oracle/oradata/primary/sysaux01.dbf /u01/app/oracle/oradata/primary/system01.dbf
mv /u01/app/oracle/oradata/primary/b /u01/app/oracle/oradata/primary/sysaux01.dbf
再次尝试打开数据库:
sql> alter database open;
database altered.
sql> select * from dual;
dum
---
x
经过以上实验的演示将数据文件重新对应，最终得以顺利打开数据库。
启示：
数据文件头部记录都记录着dbid,db_name,file number,blsize等信息，同时数据块也通过rdba标识着该数据块的物理位置（数据文件+数据块），因此可以通过这些信息与控制文件的信息做对照。
-------------------------------------------------------------------------------------------------
本文来自于我的技术博客 http://blog.csdn.net/robo23
转载请标注源文链接,否则追究法律责任!