ORA-00354: corrupt redo log block header
ORA-00353: log corruption near block 10240change 11125950022 time 05/08/2015 22:00:41
ORA-00334: archived log:'/data/oracle/oradgdata/standby_archive/1_32350_821708334.dbf'
Recovery interrupted!
Wed May 13 13:26:08 2015
Trace dumping is performingid=[cdmp_20150513132608]
Wed May 13 13:26:08 2015
Sweep [inc][273026]: completed
Recovered data files to a consistent stateat change 11125946527
Errors in file/oracle/app/oracle/diag/rdbms/pddgunq/powerdes/trace/powerdes_pr00_21813.trc:
ORA-00354: corrupt redo log block header
ORA-00353: log corruption near block 10240change 11125950022 time 05/08/2015 22:00:41
ORA-00334: archived log:'/data/oracle/oradgdata/standby_archive/1_32350_821708334.dbf'
MRP0: Background Media Recovery processshutdown (powerdes)
Wed May 13 13:39:58 2015
Standby controlfile consistent with primary
RFS[3]: Selected log 5 for thread 1sequence 32488 dbid -903205653 branch 821708334
Wed May 13 13:39:58 2015
Archived Log entry 24243 added for thread 1sequence 32487 ID 0xca2ab4eb dest 3:
分析：
这表明standby已经无法应用归档了，在32350这个归档日志错误，但是归档日志文件/data/oracle/oradgdata/standby_archive/1_32350_821708334.dbf存在，只是无法应用了。
以前使用Duplicate target database命令恢复线上oracle datagard备库，但是这个是整个库恢复，消耗时间比较长；想到oracle还有一种可以基于scn的方式来恢复standby库，所以才有那个基于scn的增量备份来恢复standby库。
1，去备库查询下未归档的记录的起始值
SQL> select min(sequence#) fromv$archived_log where applied='NO'? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
?2? ;? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
MIN(SEQUENCE#)
--------------
? ? ? ? ? 32350
SQL> select max(sequence#) fromv$archived_log where applied='NO';? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
MAX(SEQUENCE#)
--------------
? ? ? ? ? 32508
SQL>
看到从32350到32508，都是没有应用的归档日志记录。
2，去主库查询增量备份需要的SCN号
去主库查询下传输过来的32530归档日志所对应的scn号，查询sql如下：
SELECT SEQUENCE#,to_char(FIRST_CHANGE#)fc,to_char(NEXT_CHANGE#)nc FROM v$archived_log WHERE SEQUENCE# > 32349 ORDERBY 1;
SELECT SEQUENCE#,to_char(FIRST_CHANGE#)fc,to_char(NEXT_CHANGE#)nc FROM v$archived_log WHERE SEQUENCE# = 32350 ORDER BY1;
SQL> SELECT SEQUENCE#,to_char(FIRST_CHANGE#)fc,to_char(NEXT_CHANGE#)nc FROM v$archived_log WHERE SEQUENCE# = 32350 ORDER BY1;? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
?SEQUENCE# FC? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? NC
-------------------------------------------------- ----------------------------------------
? ? 32350 11125946510? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 11125975101
? ? 32350 11125946510? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 11125975101
?
SQL>
我们看到主库32350归档日志在主库对应的FIRST_CHANGE#的scn号是11125946510
去主备库检查下scn，可以看到彼此scn不一致：
select to_char(current_scn) scn fromv$database;
主库：
SQL> select to_char(current_scn) scnfrom v$database;? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
?
SCN
----------------------------------------
11134239189
?
SQL>
备库：
SQL> select to_char(current_scn) scnfrom v$database;? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
?
SCN
----------------------------------------
11125946526
?
SQL>?
也可以按照备库的最后一个scn号来在主库上进行增量备份，不过为了保险起见，我们以主库的scn号为准，那么就需要基于11125946510这个scn号去主库上做增量备份。
3，在主库上设置log_archive_dest_state_2值，主库的日志无法归档到备库.
先查询自己的归档目录select * from V$ARCHIVE_DEST;
PS：select * from V$ARCHIVE_DEST;查询到STATUS为VALID的