Re: Log apply services with RMAN

On Apr 30, 1:08 pm, sfa..._at_gmail.com wrote:
> I've just re-synced our Oracle 9.2.0.6 / Solaris 10 standby server.
> Replication was broken for a while. I had to to a recover automatic
> standby database since for some reason the secondary server could not
> retrieve over the network the archived redo log files it needed.
> I started up managed standby database disconnect from session. Every
> thing look well.
>
> But now when I run the following SQL statement on the standby server,
> I see one of the logs hasn't been applied (sequence 51112) as seen
> below:
>
> select SEQUENCE# ,FIRST_TIME NEXT_CHANGE#,APPLIED from v$archived_log
> order by 1;
>
> 51110 30-APR-07 YES
> 51111 30-APR-07 YES
> 51112 30-APR-07 NO
> 51113 30-APR-07 YES
> 51114 30-APR-07 YES
> 51115 30-APR-07 YES
> 51116 30-APR-07 YES
>
> I tried to manually register the log file which physically was on the
> standby server using :
>
> alter database register logfile '/oracle/PRD/saparch/
> PRDarch1_51112.dbf''
>
> and I get the following error :
>
> Register archivelog /oracle/PRD/saparch/PRDarch1_51112.dbf already
> exists.
>
> So I ran the sql command ALTER DATABASE RECOVER MANAGED STANDBY
> DATABASE CANCEL;
> Followed by
> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM
> SESSION;
>
> I run the script from above to query v$archived_log yet sequence 51112
> still shows as not applied. I can open the standby database in read
> only mode (something I thought would generate an error that media
> recover was needed) but it opened read only.
>
> Also, on the secondary server the following query returns no rows.
>
> SELECT * FROM V$ARCHIVE_GAP;
>
> Running this query on the standby :
>
> SELECT MESSAGE FROM V$DATAGUARD_STATUS;
> The output starts with sequence 51116.
>
> Trying to run recovery on the standby server:
>
> SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
> SQL> recover automatic standby database
> ORA-00279: change 2826047002 generated at 04/30/2007 15:53:05 needed
> for thread 1
> ORA-00289: suggestion : /oracle/PRD/saparch/PRDarch1_51130.dbf
> ORA-00280: change 2826047002 for thread 1 is in sequence #51130
> ORA-00278: log file '/oracle/PRD/saparch/PRDarch1_51130.dbf' no longer
> needed
> for this recovery
> ORA-16145: archival for thread# 1 sequence# 51130 in progress
>
> Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
>
> /oracle/PRD/saparch/PRDarch1_51112.dbf
>
> ORA-16145: archival for thread# 1 sequence# 51130 in progress
>
> Anyone have any ideas why that sequence is show as not applied?

My guess is there were no transactions in that log, since it was able to apply later logs. My other guess is a bug that didn't update whatever archived_logs looks at. In your original production alert log, does it say which thread 51112 was? If thread 1, no problem (oracle handled it), otherwise there may be future stickiness. How much time elapsed between creation of logs 51111,2 and 3? What does the standby alert log say about those three?

jg

--
@home.com is bogus.
"'Scuse me, while I kiss this guy!" - Jimi Hendrix, pointing at bass
player, in concert.