Tue Oct 28 12:17:07 2014
Primary database is in MAXIMUM PERFORMANCE mode
Tue Oct 28 12:17:07 2014
RFS[1]: Assigned to RFS process 49545378
RFS[1]: Selected log 21 for thread 1 sequence 261 dbid -512063538 branch 856885056
RFS[2]: Assigned to RFS process 58654738
RFS[2]: Selected log 22 for thread 1 sequence 262 dbid -512063538 branch 856885056
Archived Log entry 9 added for thread 1 sequence 261 ID 0xffffffffe179e6f6 dest 1:
Tue Oct 28 12:19:52 2014
Archived Log entry 10 added for thread 1 sequence 262 ID 0xffffffffe179e6f6 dest 1:
Tue Oct 28 12:19:52 2014
RFS[2]: Selected log 21 for thread 1 sequence 263 dbid -512063538 branch 856885056
Tue Oct 28 12:21:11 2014
alter database recover managed standby database using current logfile disconnect
Attempt to start background Managed Standby Recovery process (DEMO3)
Tue Oct 28 12:21:11 2014
MRP0 started with pid=26, OS id=44957722
MRP0: Background Managed Standby Recovery process started (DEMO3)
started logmerger process
Tue Oct 28 12:21:16 2014
Managed Standby Recovery starting Real Time Apply
Parallel Media Recovery started with 16 slaves
Waiting for all non-current ORLs to be archived...
All non-current ORLs have been archived.
Media Recovery Log /oracle/oradata/demo3/arch/1_253_856885056.dbf
Errors with log /oracle/oradata/demo3/arch/1_253_856885056.dbf
MRP0: Background Media Recovery terminated with error 328
Errors in file /oracle/orademo3/diag/rdbms/demo3dg/DEMO3/trace/DEMO3_pr00_60621052.trc:
ORA-00328: archived log ends at change 12478008353750, need later change 12478008373749
ORA-00334: archived log: '/oracle/oradata/demo3/arch/1_253_856885056.dbf'
Managed Standby Recovery not using Real Time Apply
Recovery interrupted!
Completed: alter database recover managed standby database using current logfile disconnect
MRP0: Background Media Recovery process shutdown (DEMO3)
使用如下方式发现不行 。
Solution
-To resolve this GAP Please follow these steps:
1- Run the following query to determine the needed logfile
SQL> select name, thread#, sequence#, archived, applied, status from
v$archived_log where 12478008373749 between FIRST_CHANGE# and NEXT_CHANGE#;
2- Recopy the logfile from the primary to the standby server
3- Register the logfile
SQL> alter database register logfile '';
4- start media recovery
SQL> alter database recover automatic managed standby database disconnect from session;
参考http://hendrydasan.wordpress.com/2011/02/21/ora-00328-archived-log-ends-at-change-29604569404-need-later-change-29605086441/ ，发现现象非常相似， 使用其中提到的 Using RMAN Incremental Backups to Roll Forward a Physical Standby Database
http://download.oracle.com/docs/cd/B19306_01/server.102/b14239/scenarios.htm#CIHIAADC 进行修复，无奈RMAN Incremental Backups 时间太长， 最终放弃，所以具体这种方式是否可以roll forward a physical standby database 还不清楚。
最后只有重新实施physical standby 。