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 Name='PROD'

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:

總結

以上是生活随笔為你收集整理的oracle block media recovery,Oracle非归档模式Media Recovery错误之--ORA-26040的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。