ORA-26040: 版. ..浣跨. NOLOGGING .」 .浇
Thu Dec 26 20:21:05 2013
Sweep [inc][28066]: completed
Sweep [inc][28065]: completed
Sweep [inc][24223]: completed
Sweep [inc][24222]: completed
看了一下，再看看表18:15，这坏块估计是那个开发的，在创建表，索引是估计加了nologging引起，先不管，回家再说，这段时间比较累,先补补觉！
第二天上班，再看看trace 文件：
Thu Dec 26 23:00:02 2013
Errors in file /u01/app/oracle/diag/rdbms/gtadb_s/gtadb2/trace/gtadb2_ora_20463.trc (incident=24577):
ORA-01578: ORACLE 版. .. .( .欢 17, .. 410512)
ORA-01110: 版. .欢 17: '/u01/app/oracle/datafile/gta_input_data_06.dbf'
ORA-26040: 版. ..浣跨. NOLOGGING .」 .浇
Thu Dec 26 23:00:05 2013
Sweep [inc][24577]: completed
Thu Dec 26 23:00:17 2013
DDE: Problem Key 'ORA 1578' was completely flood controlled (0x6)
Further messages for this problem key will be suppressed for up to 10 minutes
Thu Dec 26 23:00:24 2013
DDE: Problem Key 'ORA 1578' was completely flood controlled (0x6)
Further messages for this problem key will be suppressed for up to 10 minutes
Thu Dec 26 23:16:02 2013
又报后面的错， 百度了一下DDE: Problem Key 'ORA 1578' was completely flood controlled (0x6) ，和猜测一样，说是trace 文件比较频繁，所以。。。。。
开始动手了：
通过 v$archived_gap,v$recovery_log,v$recover_file 都显示no row
通过DBV FILE 体检一下,
SQL> l
1 SELECT SEGMENT_TYPE,OWNER||'.'||SEGMENT_NAME
2 FROM DBA_EXTENTS
3 WHERE FILE_ID = 17 AND 410512 BETWEEN BLOCK_ID
4* AND BLOCK_ID+BLOCKS -1
SEGMENT_TYPE||'.'||SEGMENT_NAME
--------------------------------------------------------------------------------
INDEX.IUM46669939
看来看，原来是一条索引，好办， 同时心想，难道我忘记了forcelogging？ 创建dg 的时候？？
于是，毫不犹豫的 v$database 看了一下，还真是！ 于是毫不犹豫在primary 上执行 alter database force logging!
通知通过user_indexes 查看这索引到底属于那张表：
SQL> select index_name,index_type,TABLE_OWNER,table_name,logging,TABLESPACE_NAME from user_indexes where index_name='IUM46669939';
INDEX_NAME INDEX_TYPE TABLE_OWNER TABLE_NAME LOG TABLESPACE_NAME
------------------------------ --------------------------- ------------------------------ ------------------------------ --- ------------------------------
IUM46669939 NORMAL INPUT TBL_ZZ_I_PERF YES GTA_INPUT_DATA
最后，通过沟通，查看，这张表上午基本没有操作，于是毫不犹豫 rebuild indexes , 强制切换日志，查看备库，ok ! 问题解决。
当然，如果是控制文件，或者其他就更具不同 而解决了！ 不管bbed ，aul 或者dul , 我觉得，备份对于DBA 来说，重于一切！
DBA 必须将两份文件保持为最新状态： 一份是好的简历，一份是最近的备份！ --我觉得比较赞！