在做db 做不完全恢复的时候，可能会遇到如下错误：
ORA-01113: file 6 needs media recovery
ORA-01110: data file 6: '/oradata/ora11/test02.dbf'
当我们recover 时候，归档文件有丢失，就会报以上的错误。 在这种情况下，可以设置初始化参数：_allow_resetlogs_corruption＝true，这样在Oracle 启动时，不再检测datafil的一致性，但是如果有文件损坏，文件要进行恢复等等，还会有不能open的报错提示。
还有一种方法就是通过BBED 命令，修改file header reset，让datafile 保持一致。 但是这种仅仅是手工的设置，虽然可以把DB强行拉起来，还是会可能导致其他的问题。
如果不能进行修复，就只能将对应的datafile 进行offline。
为了演示用BBED 修改file header reset。我们先模拟一下这种情况。模拟的方式很多，不完全恢复可以报这个错误，offlinedatafile然后online 也会提示这个错误。 只要datafile scn 信息不一致，就达到了我们的目的。
这里演示将datafile offline
然后通过bbed修改datafile header的scn,使得每个datafile 的scn一致，但是offline的datafile的scn在control file 是不一致的，比其他的scn 少，由于snc不一致，导致数据库不能开启，处理方法：
1、 先通过比对system01.dbf的datafile header的内容来修改offline datafile的datafile header。
2、 重建控制文件
3、 用带*._allow_resetlogs_corruption=TRUE的pfile启库到mount状态
4、 用open resetlogs强制打开上述数据库
5、 最后shutdown immediate再startup
SQL> alter database datafile 6 offline;
Database altered.
SQL> create table a as select * from all_objects;
Table created.
SQL> update a set object_id=100;
71453 rows updated.
SQL> commit;
Commit complete.
SQL> alter database datafile 6 online;
alter database datafile 6 online
*
ERROR at line 1:
ORA-01113: file 6 needs media recovery
ORA-01110: data file 6: '/oradata/ora11/test02.dbf'
查看控制文件里的SCN
SQL> select file#,checkpoint_change# from v$datafile;
FILE# CHECKPOINT_CHANGE#
---------- ------------------
1 1598509
2 1598509
3 1598509
4 1598509
5 1598509
6 1595805
6 rows selected.
查看需要恢复datafile 的SCN:
SQL> select file#,online_status,change# from v$recover_file;
FILE# ONLINE_ CHANGE#
---------- ------- ----------
6 OFFLINE 1595805
The file header is stored in the first block of the data file.We can use bbed to examine the block and show the block map. The header blockscontain a single data structure - kcvfh.
datafile 的file header 存储在第一个block里。
Oracleconsiders four attributes of this data structure when determining if a datafile is sync with the other data files of the database:
（1）kscnbas (at offset 484) - SCN of last change to the datafile.
（2）kcvcptim (at offset 492) -Time of the last change to the datafile.
（3）kcvfhcpc (at offset 140) - Checkpoint count.
（4）kcvfhccc (at offset 148) - Unknown, but is always 1 less than thecheckpoint point count.
Oracle有4个属性来判断datafile 是否和其他的datafile 一致，如果都一致，可以正常操作，如果不一致，那么会报ORA-01113错误。
Thefirst two attributes are stored in the kcvfhckp sub-structure. The second twoare attributes in their own right.
Wecan use the print command to display them all for the file that requiresrecovery:
BBED> set dba 6,1
DBA 0x01800001 (25165825 6,1)
BBED> p kcvfhckp
struct kcvfhckp, 36 bytes @484
struct kcvcpscn, 8 bytes @484
ub4 kscnbas @484 0x0018599d （该值为file6 的scn值）
ub2 kscnwrp @488 0x0000
ub4 kcvcptim @492 0x2dec9159
ub2 kcvcpthr @496 0x0001
union u, 12 bytes @500
struct kcvcprba, 12 bytes @500
ub4 kcrbaseq @500 0x00000019
ub4 kcrbabno @504 0x00003d3a
ub2 kcrbabof @508 0x0010
ub1 kcvcpetb[0] @512 0x02
ub1 kcvcpetb[1] @513 0x00
ub1 kcvcpetb[2] @514 0x00
ub1 kcvcpetb[3] @515 0x00
BBED> p kcvfhcpc
ub4 kcvfhcpc @140 0x00000013
BBED> p kcvfhccc
ub4 kcvfhccc @148 0x00000012
从上面可以看到datafile 6的SCN 是0x0018599d，转换一下：
SQL> select to_number('0018599d','xxxxxxxx') from dual;
TO_NUMBER('0018599D','XXXXXXXX')
--------------------------------
1595805
和上面的查看得到的需要恢复的SCN一样（同file6 的scn一致）
BBED> d /v dba 6,1 offset 484 count 64
File: /oradata/ora11/test02.dbf (6)
Block: 1 Offsets: 484 to 547 Dba:0x01800001
-------------------------------------------------------
9d591800 00000000 5991ec2d 01000000 l .Y......Y.ì-....
19000000 3a3d0000 10000000 02000000 l ....:=..........
00000000 00000000 00000000 00000000 l ................
00000000 00000000 00000000 00000000 l ................
<16 bytes per line>
这里面存储的格式和我们看到的相反。 这个在bbed 理论那片里也提到了这点：the numbers are stored in little endian format (the low-order byte of thenumber is stored in memory at the lowest address) as this example database isrunning on Linux on an Intel platform.
现在我们要做的，就是使用BBED 命令，修改datafile 6的4个属性，让其和其他的datafile 一致。
现在看一下system datafile 的4个属性值，然后修改到datafile 6上。
BBED> set dba 1,1
DBA 0x00400001 (4194305 1,1)
BBED> p kcvfhckp
struct kcvfhckp, 36 bytes @484
struct kcvcpscn, 8 bytes @484
ub4 kscnbas @484 0x0018642d
ub2 kscnwrp @488 0x0000
ub4 kcvcptim @492 0x2dec92e6
ub2 kcvcpthr @496 0x0001
union u, 12 bytes @500
struct kcvcprba, 12 bytes @500
ub4 kcrbaseq @500 0x0000001a
ub4 kcrbabno @504 0x00000002
ub2 kcrbabof @508 0x0010
ub1 kcvcpetb[0] @512 0x02
ub1 kcvcpetb[1] @513 0x00
BBED> p kcvfhcpc
ub4 kcvfhcpc @140 0x00000087
BBED> p kcvfhccc
ub4 kcvfhccc @148 0x00000086
SQL> select to_number('0018642d','xxxxxxxx') from dual;
TO_NUMBER('0018642D','XXXXXXXX')
--------------------------------
1598509
修改datafile 6的4个对应属性，注意一个一个问题，我们看到的值，在intel 的little endian是低位先存储，即顺序与我们看到的是相反的。
在用bbed修改datafile header scn时，需要考虑的四个参数：
ub4 kscnbas @484 0x0018642d à2d641800
ub4 kcvcptim @492 ox2dec92e6 àe692ec2d
ub4 kcvfhcpc @140 0x00000087 -->87000000
ub4 kcvfhccc @148 0x00000086 -->86000000
这个可以通过dump 对应的offset 进行确认
BBED> d /v dba 1,1 offset 484
File: /oradata/ora11/system01.dbf (1)
Block: 1 Offsets: 484 to 547 Dba:0x00400001
-------------------------------------------------------
2d641800 00000000 e692ec2d 01000000 l -d......æ.ì-....
1a000000 02000000 10000000 02000000 l ................
00000000 00000000 00000000 00000000 l ................
00000000 00000000 00000000 00000000 l ................
<16 bytes per line>
BBED> d /v dba 1,1 offset 492
File: /oradata/ora11/system01.dbf (1)
Block: 1 Offsets: 492 to 555 Dba:0x00400001
-------------------------------------------------------
e692ec2d 01000000 1a000000 02000000 l æ.ì-............
10000000 02000000 00000000 00000000 l ................
00000000 00000000 00000000 00000000 l ................
00000000 00000000 00000000 00000000 l ................
<16 bytes per line>
BBED> d /v dba 1,1 offset 140
File: /oradata/ora11/system01.dbf (1)
Block: 1 Offsets: 140 to 203 Dba:0x00400001
-------------------------------------------------------
87000000 794dec2d 86000000 00000000 l ....yMì-........
00000000 00000000 00000000 00000000 l ................
00000000 00000000 00000000 00000000 l ................
00000000 00000000 00000000 00000000 l ................
<16 bytes per line>
BBED> d /v dba 1,1 offset 148
File: /oradata/ora11/system01.dbf (1)
Block: 1 Offsets: 148 to 211 Dba:0x00400001
-------------------------------------------------------
86000000 00000000 00000000 00000000 l ................
00000000 00000000 00000000 00000000 l ................
00000000 00000000 00000000 00000000 l ................
00000000 00000000 00000000 00000000 l ................
<16 bytes per line>
BBED> modify /x e692ec2c dba 6,1 offset 492
BBED-00209: invalid number (e692ec2c)
(注意：可以逐渐减少该值)
BBED> modify /x e692 dba 6,1 offset 492
File: /oradata/ora11/test02.dbf (6)
Block: 1 Offsets: 492 to 555 Dba:0x01800001
------------------------------------------------------------------------
e6922ec2 01000000 19000000 3a3d0000 10000000 02000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
<32 bytes per line>
BBED> modify /x 87 dba 6,1 offset 140
File: /oradata/ora11/test02.dbf (6)
Block: 1 Offsets: 140 to 203 Dba:0x01800001
------------------------------------------------------------------------
87000000 5091ec2d 12000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
<32 bytes per line>
BBED> modify /x 86 dba 6,1 offset 148
File: /oradata/ora11/test02.dbf (6)
Block: 1 Offsets: 148 to 211 Dba:0x01800001
------------------------------------------------------------------------
86000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
<32 bytes per line>
BBED> sum dba 6,1 apply
Check value for File 6, Block 1:
current = 0x985f, required = 0x985f
应用变跟之后，尝试onlinedatafile 6 还是失败。
SQL> select file#,checkpoint_change# from v$datafile;
FILE# CHECKPOINT_CHANGE#
---------- ------------------
1 1598509
2 1598509
3 1598509
4 1598509
5 1598509
6 1595805
6 rows selected.
查看需要恢复datafile 的SCN:
SQL> select file#,online_status,change# from v$recover_file;
FILE# ONLINE_ CHANGE#
---------- ------- ----------
6 OFFLINE 1598509
这里要注意v$datafile里的结果。 虽然我们修改了datafile header里的几个值，但是v$datafile里的scn并没有改变，因为这里的scn是从控制文件里读取的。 而BBED 不能修改控制文件，所以，对于offline datafile 的方法，只使用bbed 就行不通，还需要做一些其他的操作。
如果是startup 阶段遇到这个问题，那么就完全可以使用bbed 搞定这个问题。
oracle在对某个datafile做offline的时候实际上是相当于offline immediate，此时不会改datafile header中的内容，而只是修改control文件，等到再想online的时候一定要做recovery，从而让控制文件和datafile里的scn 一致。DSI 403e中的描述：
Offline normal (tablespace)：
1、Checkpoints data blocks oftablespace
2、Updates file headers and controlfile
Offline immediate (tablespace or data file)：
1、Only update control file
2、Data files require recovery
在这种情况下，恢复的大致步骤如下：
1、 先通过比对system01.dbf的datafile header的内容来修改datafile的datafile header。
2、 重建控制文件
3、 用带*._allow_resetlogs_corruption=TRUE的pfile启库到mount状态
4、 用open resetlogs强制打开上述数据库
5、 最后shutdown immediate再startup
修改datafile header 我们已经做过了，我们重新一下控制文件。
SQL> alter database backup controlfile to trace;
查找trace文件
sql>startup nomount;
sql>CREATE CONTROLFILE REUSE DATABASE "ORA11" RESETLOGS ARCHIVELOG
MAXLOGFILES 16
MAXLOGMEMBERS 3
MAXDATAFILES 100
MAXINSTANCES 8
MAXLOGHISTORY 292
LOGFILE
GROUP 1 '/oradata/ora11/redo01.log' SIZE 50M BLOCKSIZE 512,
GROUP 2 '/oradata/ora11/redo02.log' SIZE 50M BLOCKSIZE 512,
GROUP 3 '/oradata/ora11/redo03.log' SIZE 50M BLOCKSIZE 512
-- STANDBY LOGFILE
DATAFILE
'/oradata/ora11/system01.dbf',
'/oradata/ora11/sysaux01.dbf',
'/oradata/ora11/undotbs01.dbf',
'/oradata/ora11/users01.dbf',
'/oradata/ora11/test01.dbf',
'/oradata/ora11/test02.dbf'
CHARACTER SET AL32UTF8
;
SQL>alter database open;
ERROR at line 1:
ORA-01113: file 6 needs media recovery
ORA-01110: data file 6: '/oradata/ora11/test02.dbf'
SQL> recover datafile 6;
Media recovery complete.
Sql>alter database open;
或是利用修改初始化参数，添加*._allow_resetlogs_corruption=TRUE
来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/24849178/viewspace-714127/，如需转载，请注明出处，否则将追究法律责任。
转载于:http://blog.itpub.net/24849178/viewspace-714127/
1037
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
