11、转储对应的logfile
14:35:48 SYS@ prod>alter system dump logfile '/dsk1/oradata/prod/redo01a.log'；
System altered.
14:35:53 SYS@ prod>alter system dump logfile '/dsk1/oradata/prod/redo03a.log'；
System altered.
[Oracle@rh6 ~]$ cat /u01/app/oracle/diag/rdbms/prod/prod/trace/prod_ora_2406.trc
DUMP OF REDO FROM FILE '/dsk1/oradata/prod/redo01a.log'
Opcodes *.*
RBAs: 0x000000.00000000.0000 thru 0xffffffff.ffffffff.ffff
SCNs: scn: 0x0000.00000000 thru scn: 0xffff.ffffffff
Times: creation thru eternity
FILE HEADER:
Compatibility Vsn = 186646528=0xb200000
Db ID=239333010=0xe43ee92, Db
Activation ID=264808982=0xfc8aa16
Control Seq=2747=0xabb, File size=102400=0x19000
File Number=1, Blksiz=512, File Type=2 LOG
descrip:"Thread 0001, Seq# 0000000004, SCN 0x000000216562-0x00000021b4dc"
thread: 1 nab: 0x11c seq: 0x00000004 hws: 0x6 eot: 0 dis: 0
resetlogs count: 0x32d7d50e scn: 0x0000.00206c24 (2124836)
prev resetlogs count: 0x32d7cc14 scn: 0x0000.0020680f (2123791)
Low scn: 0x0000.00216562 (2188642) 07/24/2014 18:27:42
Next scn: 0x0000.0021b4dc (2208988) 07/24/2014 18:35:45
Enabled scn: 0x0000.00206c24 (2124836) 07/15/2014 17:59:42
Thread closed scn: 0x0000.0021b4da (2208986) 07/24/2014 18:33:04
Disk cksum: 0x1af0 Calc cksum: 0x1af0
Terminal recovery stop scn: 0x0000.00000000
Terminal recovery 01/01/1988 00:00:00
Most recent redo scn: 0x0000.00000000
Largest LWN: 0 blocks
End-of-redo stream : No
Unprotected mode
Miscellaneous flags: 0x800000
Thread internal enable indicator: thr: 0, seq: 0 scn: 0x0000.00000000
REDO RECORD - Thread:1 RBA: 0x000004.000000c6.0198 LEN: 0x0034 VLD: 0x01
SCN: 0x0000.00216666 SUBSCN: 1 07/24/2014 18:30:45
CHANGE #1 INVLD AFN:9 DBA:0x02400083 BLKS:0x0001 OBJ:75139 SCN:0x0000.00216666 SEQ:1 OP:19.2 ENC:0
Direct Loader invalidate block range redo entry
REDO RECORD - Thread:1 RBA: 0x000006.000007b6.0110 LEN: 0x0034 VLD: 0x01
SCN: 0x0000.00220ad0 SUBSCN: 1 07/25/2014 14:22:51
CHANGE #1 INVLD AFN:2 DBA:0x0080f09c BLKS:0x0001 OBJ:6214 SCN:0x0000.00220ad0 SEQ:1 OP:19.2 ENC:0
Direct Loader invalidate block range redo entry
-在redo日志里记录了“Direct Loader”的动作（OBJ:75139，OBJ:6214）
查看对应的对象：
14:29:23 SYS@ prod>select owner,object_id,object_name from dba_objects
15:18:47 2 where object_id=75139;
OWNER OBJECT_ID OBJECT_NAME
------------------------------ ---------- --------------------
SCOTT 75139 T1
Elapsed: 00:00:00.04
15:18:51 SYS@ prod>select owner,object_id,object_name from dba_objects
15:18:58 2 where object_id=6214;
OWNER OBJECT_ID OBJECT_NAME
------------------------------ ---------- --------------------
SYS 6214 SYS_LOB0000006213C00
038$$
Elapsed: 00:00:00.05
15:19:07 SYS@ prod>
从以上，查看信息可以推断，在Media Recover阶段，create table T1和Insert table时，应该是采用了‘nologging’方式，以致后续的Insert的数据通过redo log无法被恢复，导致出现逻辑坏块！
备注：（借鉴Maclean Liu博客观点）
【数据恢复】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.584Start dump data blocks tsn: 17 file#:17 minblk 131 maxblk 131Block dump from cache:Dump of buffer cache at level 4 for pdb=0 tsn=17 rdba=71303299Block dump from disk:buffer tsn: 17 rdba: 0×04400083 (17/131)scn: 0×0.62faac seq: 0xff flg: 0×04 tail: 0xfaac00fffrmt: 0×02 chkval: 0xa2a1 type: 0×00=unknownHex dump of block: st=0, typ_found=0Dump of memory from 0x000000000BFF2200 to 0x000000000BFF420000BFF2200 0000A200 04400083 0062FAAC 04FF0000 [......@...b.....]00BFF2210 0000A2A1 FFFFFFFF FFFFFFFF FFFFFFFF [................]00BFF2220 FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF [................]Repeat 508 times00BFF41F0 FFFFFFFF FFFFFFFF FFFFFFFF FAAC00FF [................]End dump data blocks tsn: 17 file#: 17 minblk 131 maxblk 131
scn: 0×0.62faac seq: 0xff
==》 对应的SCN为6486700，可以看到内容除了头部一点外 全是0XFF
dump 对应redo logfile 可以看到
REDO RECORD – Thread:1 RBA: 0×000074.00015418.0078 LEN: 0x003c VLD: 0×01 CON_UID: 0SCN: 0×0000.0062faac SUBSCN: 1 09/26/2013 10:04:39CHANGE #1 INVLD CON_ID:0 AFN:17 DBA:0×04400083 BLKS:0x000d OBJ:123054 SCN:0×0000.0062faac SEQ:1 OP:19.2 ENC:0Direct 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 theformat used by Oracle to mark a block as corrupt due to redo invalidation(NOLOGGING).NOLOGGING OPERATION in redo: