5，确定归档日志有没有写到从库：
所以用的lgwr进程，用lgwr进程进行传输日志，而其他模式用arch传输日志是等到日志写到归档的过程中传输过去，最近你没有改过从库的保护模式吧。
主库上查看下redo log的大小：
select GROUP#,BYTES/1024/1024,STATUS from v$log;
SQL> select GROUP#,BYTES/1024/1024,STATUS from v$log;
GROUP# BYTES/1024/1024 STATUS
---------- --------------- ----------------
1 50 CURRENT
2 50 INACTIVE
3 50 ACTIVE
SQL>
确定日志有没有写到从库：
执行： select name,sequence#,applied from v$archived_log;
NAME
--------------------------------------------------------------------------------
SEQUENCE# APPLIED
---------- ---------
/Oracle/app/oracle/flash_recovery_area/archivelog/1_24161_821708334.dbf
24161 NO
/oracle/app/oracle/flash_recovery_area/archivelog/1_24162_821708334.dbf
24162 NO
从库上归档日志：
NAME
--------------------------------------------------------------------------------
SEQUENCE# APPLIED
---------- ---------
/data/oracle/oradgdata/standby_archive/1_24072_821708334.dbf
24072 NO
2800 rows selected.
看到这里，从库上，最后一个日志是24072，比主库上的24162要低很多，
再去查下主库的归档日志路径：
select name from v$archived_log;找到归档日志路径/oracle/app/oracle/flash_recovery_area/archivelog/
ll /oracle/app/oracle/flash_recovery_area/archivelog/看到最后一个归档日志是：
-rw-r----- 1 oracle oinstall 2808832 Jul 22 09:24 1_24162_821708334.dbf
-rw-r----- 1 oracle oinstall 3072512 Jul 22 09:30 1_24163_821708334.dbf
再去主库的归档日志路径上面check下，是否有从库最后一个归档日志24072
[oracle@localhost ~]$ ll /oracle/app/oracle/flash_recovery_area/archivelog/*24072*.dbf
-rw-r----- 1 oracle oinstall 1992704 Jul 22 01:00 /oracle/app/oracle/flash_recovery_area/archivelog/1_24072_821708334.dbf
[oracle@localhost ~]$
检查下主库从库的归档管理模式
从库：
SQL> show parameter standby_file_management;
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
standby_file_management string MANUAL
SQL>
主库：
SQL> show parameter standby_file_management;
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
standby_file_management string AUTO
SQL>
看到从库跟主库不一致，需要手动将从库上面的MANUAL修改成AUTO。
alter system set standby_file_management='AUTO';
SQL> alter system set standby_file_management='AUTO';
System altered.
SQL>
SQL> show parameter standby_file_management;
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
standby_file_management string AUTO
SQL>
去主库上查看一下归档日志的状态
SQL> show parameter log_archive_dest_state_2;
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
log_archive_dest_state_2 string ENABLE
log_archive_dest_state_20 string enable
log_archive_dest_state_21 string enable
log_archive_dest_state_22 string enable
log_archive_dest_state_23 string enable
log_archive_dest_state_24 string enable
log_archive_dest_state_25 string enable
log_archive_dest_state_26 string enable
log_archive_dest_state_27 string enable
log_archive_dest_state_28 string enable
log_archive_dest_state_29 string enable
SQL>
6，检查alert信息
因为主库1点有oracle归档日志，所以去主库从库看下alert日志信息：
主库信息：
ll /oracle/app/oracle/diag/rdbms/pdunq/powerdes/trace/alert_powerdes.log
Tue Jul 22 01:00:02 2014
ALTER SYSTEM ARCHIVE LOG
Tue Jul 22 01:00:02 2014
Thread 1 advanced to log sequence 24073 (LGWR switch)
Current log# 1 seq# 24073 mem# 0: /home/oradata/powerdes/redo01.log
Archived Log entry 46639 added for thread 1 sequence 24072 ID 0xca2ab4eb dest 1:
Tue Jul 22 01:00:17 2014
Errors in file /oracle/app/oracle/diag/rdbms/pdunq/powerdes/trace/powerdes_lgwr_15950.trc:
ORA-16086: Redo data cannot be written to the standby redo log
LGWR: Failed to archive log 2 thread 1 sequence 24074 (16086)
Thread 1 advanced to log sequence 24074 (LGWR switch)
Current log# 2 seq# 24074 mem# 0: /home/oradata/powerdes/redo02.log
Tue Jul 22 01:00:19 2014
Archived Log entry 46641 added for thread 1 sequence 24073 ID 0xca2ab4eb dest 1:
Tue Jul 22 01:02:28 2014
backup piece header validation failure for handle /data/oracle/backup/data/ctl_auto/c-3391761643-20140721-00
backup piece header validation failure for handle /data/oracle/backup/data/ctl_auto/c-3391761643-20140721-01
ll /oracle/app/oracle/diag/rdbms/pddgunq/powerdes/trace/alert_powerdes.log
从库信息：
Tue Jul 22 01:04:48 2014
RFS[8692]: Assigned to RFS process 10970
RFS[8692]: Identified database type as 'physical standby': Client is ARCH pid 16028
Tue Jul 22 01:04:49 2014
RFS[8693]: Assigned to RFS process 10972
RFS[8693]: Identified database type as 'physical standby': Client is LGWR SYNC pid 15950
Primary database is in MAXIMUM AVAILABILITY mode
Standby controlfile consistent with primary
Standby controlfile consistent with primary
RFS[8693]: No standby redo logfiles selected (reason:7)
Errors in file /oracle/app/oracle/diag/rdbms/pddgunq/powerdes/trace/powerdes_rfs_10972.trc:
ORA-16086: Redo data cannot be written to the standby redo log
Tue Jul 22 01:10:48 2014
RFS[8694]: Assigned to RFS process 10989
RFS[8694]: Identified database type as 'physical standby': Client is ARCH pid 16028
Tue Jul 22 01:10:51 2014
RFS[8695]: Assigned to RFS process 10992
RFS[8695]: Identified database type as 'physical standby': Client is LGWR SYNC pid 15950