存在活跃事务时，UNDO被删除，数据库ABORT时的恢复

今天朋友问我，如果存在活跃事务时，UNDO表空间相关的数据文件被删除，然后ABORT库，数据库启动报错，隐含参数也无法拉起库

如果是正常关闭的库，由于DBWR进程会一直持有数据文件的句柄，其一般能保证数据库正常的关闭。这是UNDO丢失恢复也很简单。
如果ORACLE能在ABORT前，发现损坏，那么ORACLE启动时，通过隐含参数也可以OFFLINE掉UNDO段
但是在ORACLE报错前，直接ABORT的库，可能某些元数据不一致或存在问题，需要读取UNDO，这是找不到UNDO就会报错

注意，SYSTEM表空间中的UNDO段，只保存元数据的UNDO数据，但是并不是元数据的UNDO数据只放在SYSTEM表空间中的UNDO段。

这是，无论使用任何隐含参数，都无法打开库，报错：
Sat Mar 26 16:47:19 2011
Errors in file /u01/app/oracle/admin/O10204/udump/o10204_ora_12544.trc:
ORA-00704: bootstrap process failure
ORA-00604: error occurred at recursive SQL level 2
ORA-00376: file 2 cannot be read at this time
ORA-01110: data file 2: '/oradata/oracle10/O10204/undotbs01.dbf'

bootstrap阶段报错。出错的语句是个SELECT，应该是为维护一致性读的报错。
用了隐含参数也无法将UNDO段个OFFLINE掉，所以启动也报错

这是，可以用bbed将undo$中的记录强制标记为OFFLINE
undo$中数据位置一般在块106

BBED> set dba 1,106
        DBA             0x0040006a (4194410 1,106)

可以看到，这个库有11个UNDO SEGMENTS

BBED> p kdbr
sb2 kdbr[0]                                 @86       8079
sb2 kdbr[1]                                 @88       7059
sb2 kdbr[2]                                 @90       7112
sb2 kdbr[3]                                 @92       7165
sb2 kdbr[4]                                 @94       7218
sb2 kdbr[5]                                 @96       7271
sb2 kdbr[6]                                 @98       7324
sb2 kdbr[7]                                 @100      7377
sb2 kdbr[8]                                 @102      7431
sb2 kdbr[9]                                 @104      7485
sb2 kdbr[10]                                @106      7539

BBED> p *kdbr[1]  
rowdata[0]
----------
ub1 rowdata[0]                              @7127     0x2c

看看每条数据

BBED> x /1rncnnnnnnnnnnn
rowdata[0]                                  @7127   
----------
flag@7127: 0x2c (KDRHFL, KDRHFF, KDRHFH)
lock@7128: 0x00
cols@7129:   17

col    0[2] @7130: 1
col    1[9] @7133: _SYSSMU1$
col    2[2] @7143: 1
col    3[2] @7146: 2
col    4[2] @7149: 9
col    5[4] @7152: 56749
col    6[1] @7157: 0
col    7[2] @7159: 51
col    8[2] @7162: 23
col    9[1] @7165: 0
col   10[2] @7167: 3                 -- 这里的3，代表ONLINE
col   11[2] @7170: 1
col   12[0] @7173: *NULL*
col   13[0] @7174: *NULL*
col   14[0] @7175: *NULL*
col   15[0] @7176: *NULL*
col   16[2] @7177: 1

可以用bbed，强制将其修改为2，代表OFFLINE，然后就能不用隐含参数OPEN库

set offset 7167    -- COL10的位置
set offset +2      -- 跳过COL头
modify /x 03       -- 修改为2(OFFLINE),oracle减一存储

可以看到，这样和隐含参数一样，元数据可能已经不一致，数据库一定要新EXP/IMP

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/8242091/viewspace-690582/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/8242091/viewspace-690582/