一早来上班就收到User的反应，说有些数据查不到，看了他们的截图，发现可能遇到corrupted block了。赶紧上去看一下严重程度先。

08:23:11 SQL> select * from ISN where ISN='NS1S82038200461';

select * from ISN where ISN='NS1S82038200461'

*

ERROR at line 1:

ORA-01578: ORACLE data block corrupted (file # 16, block # 68845)

ORA-01110: data file 16: '/u02/app/oracle/oradata/shxxx1/isn0807_data01.dbf'

08:25:00 SQL> select file#,NAME from v$datafile where file#=16;

16

/u02/app/oracle/oradata/shxxx1/isn0807_data01.dbf

08:38:57 SQL> select * from dba_extents

08:39:22 2 where file_id=16 and block_id<=68845 and (block_id+blocks-1)>=68845;

TP ISN

ISN_0807_S5 TABLE SUBPARTITION ISN0807_TAB 8 16 68617

8388608 1024 16

DBV-00200: Block, dba 67177709, already marked corrupted

DBVERIFY - Verification starting : FILE = isn0807_data01.dbf

DBVERIFY - Verification complete

Total Pages Examined : 77824

Total Pages Processed (Data) : 68656

Total Pages Failing (Data) : 0

Total Pages Processed (Index): 0

Total Pages Failing (Index): 0

Total Pages Processed (Other): 984

Total Pages Processed (Seg) : 0

Total Pages Failing (Seg) : 0

Total Pages Empty : 8184

Total Pages Marked Corrupt : 1

Total Pages Influx : 0

Highest block SCN : 65158286119 (15.733776679)

看来真的有，联想到昨天的问题( 这个一会再提 ).

先着手处理下，还好只是一个partition table的一个subpartition。先估计一下影响范围向User打声招呼。

1． 确定Physical Standby Database的相应文件可以用。Shutdown之。

2． Cold backup standby上相应的datafile，起standby.

3． 更改cold backup出来的datafile的文件名，并SCP到Primary的对应目录下。

4． Offline有问题的datafile,并改名。

5． 将cold backup的datafile改回原名

6． recover datafile

7． Online datafile

联想到昨天Primary突然crash的问题：

先出了一些ORA-07445和ORA-600，提示block corrupted。然后DBW Terminated, Instance Crash.

见鬼的是居然Oracle连Trace都没留下就撒手了囧.

不过有一月份Crash的经验，判定还是有人用古旧版本的PL/SQL Developer导致（9208任何平台都会发生）。但是没Trace file，不晓得是哪个家伙。

从alert.log看这次的Crash导致了dbfile上的corrupted block的产生。一月份的那次只是buffer里的corrupted，今后遇到连trace 都没留下的crash要格外当心坏快问题了。