因not open force loggning 引起的DG ORA-1578 报错(二)

又报后面的错，　百度了一下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_NAMEINDEX_TYPE TABLE_OWNERTABLE_NAMELOG TABLESPACE_NAME
------------------------------ --------------------------- ------------------------------ ------------------------------ --- ------------------------------
IUM46669939NORMAL INPUTTBL_ZZ_I_PERF YES GTA_INPUT_DATA

最后，通过沟通，查看，这张表上午基本没有操作，于是毫不犹豫 rebuild indexes , 强制切换日志，查看备库，ok ! 问题解决。

当然，如果是控制文件，或者其他就更具不同 而解决了！ 不管bbed ，aul 或者dul , 我觉得，备份对于DBA 来说，重于一切！

DBA 必须将两份文件保持为最新状态： 一份是好的简历，一份是最近的备份！ --我觉得比较赞！