背景描述：Oracle 的standby库后台alert报错，如下：
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;
主库：