【数据恢复】NOLOGGING UNRECOVERABLE ORA-26040解析

 

 

SQL> select count(*) from abc;
select count(*) from abc
*
第 1 行出现错误:
ORA-01578: ORACLE 数据块损坏 (文件号 17, 块号 131)
ORA-01110: 数据文件 17:
‘C:\APP\XIANGBLI\ORADATA\MACLEAN\DATAFILE\O1_MF_NLOGGING_9475OCS5_.DBF’
ORA-26040: 数据块是使用 NOLOGGING 选项加载的

 
SQL> select UNRECOVERABLE_CHANGE# , UNRECOVERABLE_time from v$datafile where file#=17;

UNRECOVERABLE_CHANGE# UNRECOVERABLE_
——————— ————–
6486756 26-9月 -13

 

把 (文件号 17, 块号 131) dump出来看一下

 

 

*** 2013-09-26 10:07:46.584
Start dump data blocks tsn: 17 file#:17 minblk 131 maxblk 131
Block dump from cache:
Dump of buffer cache at level 4 for pdb=0 tsn=17 rdba=71303299
Block dump from disk:
buffer tsn: 17 rdba: 0x04400083 (17/131)
scn: 0x0.62faac seq: 0xff flg: 0x04 tail: 0xfaac00ff
frmt: 0x02 chkval: 0xa2a1 type: 0x00=unknown
Hex dump of block: st=0, typ_found=0
Dump of memory from 0x000000000BFF2200 to 0x000000000BFF4200
00BFF2200 0000A200 04400083 0062FAAC 04FF0000 [……@…b…..]
00BFF2210 0000A2A1 FFFFFFFF FFFFFFFF FFFFFFFF […………….]
00BFF2220 FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF […………….]
Repeat 508 times
00BFF41F0 FFFFFFFF FFFFFFFF FFFFFFFF FAAC00FF […………….]
End dump data blocks tsn: 17 file#: 17 minblk 131 maxblk 131

 

scn: 0x0.62faac seq: 0xff

==》 对应的SCN为6486700,可以看到内容除了头部一点外 全是0XFF

 

dump 对应redo logfile 可以看到

REDO RECORD – Thread:1 RBA: 0x000074.00015418.0078 LEN: 0x003c VLD: 0x01 CON_UID: 0
SCN: 0x0000.0062faac SUBSCN: 1 09/26/2013 10:04:39
CHANGE #1 INVLD CON_ID:0 AFN:17 DBA:0x04400083 BLKS:0x000d OBJ:123054 SCN:0x0000.0062faac SEQ:1 OP:19.2 ENC:0
Direct Loader invalidate block range redo entry

 

OP:19.2=》Layer 19 : Direct Loader Log Blocks – KCOCODLB Opcode 2 : Invalidate range – KCBLCOIR

==》这里在redo里标记了 直接路径加载造成块失效的范围,在redo logfile dump中可以看到大量类似数据

 

即当recover时读取redo,读到“Direct Loader invalidate block range redo entry”信息时,则将对应的数据块的内容除了kcbh头部外全部记录为0XFF

当Oracle读取到这些块时就会知道这些块是SOFT Corrupt ,原因是nologging造成的。

Block is marked as SOFT Corrupt and has 0xff along the block. This is the
format used by Oracle to mark a block as corrupt due to redo invalidation
(NOLOGGING).
NOLOGGING OPERATION in redo:

 

 

关注dbDao.com的新浪微博

扫码关注dbDao.com 微信公众号:

Comments

  1. 这个逻辑有些奇怪啊“当Oracle读取到这些块时就会知道这些块是SOFT Corrupt ,原因是nologging造成的”,数据块的corrupt和是否nologgin居然有关系?感觉这里只是表明了一个结论,但是没有说明因果关系

    • “即当recover时读取redo,读到“Direct Loader invalidate block range redo entry”信息时,则将对应的数据块的内容除了kcbh头部外全部记录为0XFF”产生这种特殊redo的的场景上面说了 append+nologging会造成。

Speak Your Mind

TEL/電話+86 13764045638
Email service@parnassusdata.com
QQ 47079569