ITPub博客

首页 > Linux操作系统 > Linux操作系统 > 存在活跃事务时,UNDO被删除,数据库ABORT时的恢复

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

原创 Linux操作系统 作者:westzq1984 时间:2011-03-26 17:22:11 0 删除 编辑
今天朋友问我,如果存在活跃事务时,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/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论

注册时间:2009-04-06

  • 博文量
    251
  • 访问量
    966753