Standby database is not completing recovery.

Question

All,
I applied a PSU to 10.2.0.4 (8576156) patch this afternoon on both the primary and standby oracle_home(s). Upon starting up the standby database, I no longer see the “media recovery waiting” message in the alert log when an archive log is sent from the primary.
Not sure if I have an issue with the patch or DG is configured or started.
Perhaps another set of eyes can lead me to an issue I am not seeing.
The standby database was started as follows:
alter database RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT FROM SESSION
Example alert log message before:
Sun Sep 13 02:20:39 2009
Primary database is in MAXIMUM PERFORMANCE mode
RFS[2]: Successfully opened standby log 4: '/oradat1/cwsiqa2/cwsiqa2_sb_redo04_a.log'
Sun Sep 13 02:20:47 2009
Media Recovery Waiting for thread 1 sequence 52 (in transit) <<== NOTE
Sun Sep 13 02:20:47 2009
Recovery of Online Redo Log: Thread 1 Group 4 Seq 52 Reading mem 0
Mem# 0: /oradat1/cwsiqa2/cwsiqa2_sb_redo04_a.log
Mem# 1: /oradat2/cwsiqa2/cwsiqa2_sb_redo04_b.log
Example alert log message after:
Primary database is in MAXIMUM PERFORMANCE mode
Tue Sep 15 15:56:27 2009
RFS[3]: Successfully opened standby log 4: '/oradat1/cwsiqa2/cwsiqa2_sb_redo04_a.log'
Tue Sep 15 15:56:27 2009
Primary database is in MAXIMUM PERFORMANCE mode
RFS[4]: Successfully opened standby log 6: '/oradat3/cwsiqa2/cwsiqa2_sb_redo06_a.log'
Tue Sep 15 15:57:05 2009
Redo Shipping Client Connected as PUBLIC
-- Connected User is Valid
RFS[5]: Assigned to RFS process 29772
RFS[5]: Identified database type as 'physical standby'
Tue Sep 15 16:12:56 2009
The same messages are listed in v$datagurd_status
1* select message from v$dataguard_status
SQL> /
MESSAGE
ARC0: Archival started
ARC1: Archival started
ARC2: Archival started
ARC3: Archival started
ARC4: Archival started
ARC5: Archival started
ARC6: Archival started
ARC7: Archival started
ARC8: Archival started
ARC9: Archival started
ARC9: Becoming the 'no FAL' ARCH
ARC9: Becoming the 'no SRL' ARCH
ARC0: Becoming the heartbeat ARCH
Attempt to start background Managed Standby Recovery process
MRP0: Background Managed Standby Recovery process started
Managed Standby Recovery starting Real Time Apply
Redo Shipping Client Connected as PUBLIC
-- Connected User is Valid
RFS[1]: Assigned to RFS process 28316
RFS[1]: Identified database type as 'physical standby'
Redo Shipping Client Connected as PUBLIC
-- Connected User is Valid
RFS[2]: Assigned to RFS process 28318
RFS[2]: Identified database type as 'physical standby'
Redo Shipping Client Connected as PUBLIC
-- Connected User is Valid
RFS[3]: Assigned to RFS process 29693
RFS[3]: Identified database type as 'physical standby'
Redo Shipping Client Connected as PUBLIC
-- Connected User is Valid
RFS[4]: Assigned to RFS process 29691
RFS[4]: Identified database type as 'physical standby'
Primary database is in MAXIMUM PERFORMANCE mode
RFS[3]: Successfully opened standby log 4: '/oradat1/cwsiqa2/cwsiqa2_sb_redo04_a.log'
Primary database is in MAXIMUM PERFORMANCE mode
RFS[4]: Successfully opened standby log 6: '/oradat3/cwsiqa2/cwsiqa2_sb_redo06_a.log'
Redo Shipping Client Connected as PUBLIC
-- Connected User is Valid
RFS[5]: Assigned to RFS process 29772
RFS[5]: Identified database type as 'physical standby'
Primary database is in MAXIMUM PERFORMANCE mode
RFS[4]: Successfully opened standby log 4: '/oradat1/cwsiqa2/cwsiqa2_sb_redo04_a.log'
Primary database is in MAXIMUM PERFORMANCE mode
RFS[4]: Successfully opened standby log 6: '/oradat3/cwsiqa2/cwsiqa2_sb_redo06_a.log'
I also have a “gap” that is not getting resolved.
SQL> select * from v$archive_gap
2 /
THREAD# LOW_SEQUENCE# HIGH_SEQUENCE#
1 53 53
SELECT MAX(R.SEQUENCE#) LAST_SEQ_RECD, MAX(L.SEQUENCE#) LAST_SEQ_SENT
2* FROM V$ARCHIVED_LOG R, V$LOG L WHERE R.DEST_ID=2 AND L.ARCHIVED='YES'
SQL> /
LAST_SEQ_RECD LAST_SEQ_SENT
54     58
Any insight would be appreciated.

Answer 1

Problem has been resolved.