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

最新推荐文章于 2025-06-24 11:19:23 发布

转载最新推荐文章于 2025-06-24 11:19:23 发布 · 1k 阅读

文章标签：

#Oracle #ORA-26040 #NOLOGGING

故障诊断专栏收录该内容

4 篇文章

订阅专栏

本文介绍了一次Oracle数据库中由于使用NOLOGGING选项加载数据导致的数据块损坏案例。文章详细展示了通过查询UNRECOVERABLE_CHANGE#及UNRECOVERABLE_TIME来定位问题，并通过分析数据文件与Redo Log文件来确定损坏的原因。

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:

原文地址：http://www.askmaclean.com/archives/nologging-unrecoverable.html