oracle undo bbed内部技术

如果是正常关闭的库，由于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