RE: data guard real time apply question

From: Sweetser, Joe <JSweetser_at_icat.com>
Date: Mon, 24 Sep 2012 15:16:32 +0000
Message-ID: <D18D6513433DF04394041EA42B53E91C9CD54F8F_at_ICATMAIL1.ICAT.com>



Issue solved. Thanks to all the responses as they certainly led me down the path of resolution. Turns out the standby redo logs were not created on my standby database so the RFS process was writing directly to archived log files.

From here: http://docs.oracle.com/cd/B19306_01/server.102/b14239/standby.htm#i72459

You can see this:

Redo data transmitted from the primary database is received by the remote file server (RFS) process on the standby system where the RFS process writes the redo data to archived log files or standby redo log files.

When building my standby I tried to take "best practice"-type stuff from multiple sources. One piece of advice I came across was this:

<snip>

create standby logfiles on the primary for two reasons, 1) it may become a standby later and would then need them, 2) when we create the standby they will be created as part of that process
<snip>

For me, the standby logfiles were not created as part of the process but - full disclosure - I did *not* use the RMAN command: duplicate target database for standby from active database. I just copied my RMAN backups over and did a restore database. My assumption is that RMAN is smart enough to create the standby redo logs when using the correct command whereas I am obviously not! Once I manually created the standby redo logs everything came together as expected.

(tail of alert log)
Mon Sep 24 08:50:04 2012
RFS[29]: Selected log 11 for thread 1 sequence 83277 dbid -<whatever> branch 765739491 Mon Sep 24 08:50:04 2012
Archived Log entry 3870 added for thread 1 sequence 83276 ID 0xb1c714a3 dest 1: Mon Sep 24 08:50:04 2012
Media Recovery Waiting for thread 1 sequence 83277 (in transit) Recovery of Online Redo Log: Thread 1 Group 11 Seq 83277 Reading mem 0   Mem# 0: /u01/oradata/<sid>/standby_redo11a.rdo   Mem# 1: /u03/oradata/<sid>/standby_redo11b.rdo

(long listing of files on disk)
ls -lart /u0*/oradata/<sid>/*rdo
<snip> 52429312 Sep 5 12:59 /u01/oradata/<sid>/online_redo01.rdo
<snip> 52429312 Sep 5 12:59 /u02/oradata/<sid>/online_redo02.rdo
<snip> 52429312 Sep 5 12:59 /u03/oradata/<sid>/online_redo03.rdo
<snip> 52429312 Sep 24 08:45 /u03/oradata/<sid>/standby_redo12b.rdo
<snip> 52429312 Sep 24 08:45 /u01/oradata/<sid>/standby_redo12a.rdo
<snip> 52429312 Sep 24 08:45 /u03/oradata/<sid>/standby_redo13b.rdo
<snip> 52429312 Sep 24 08:45 /u01/oradata/<sid>/standby_redo13a.rdo
<snip> 52429312 Sep 24 08:50 /u03/oradata/<sid>/standby_redo10b.rdo
<snip> 52429312 Sep 24 08:50 /u01/oradata/<sid>/standby_redo10a.rdo
<snip> 52429312 Sep 24 09:10 /u03/oradata/<sid>/standby_redo11b.rdo
<snip> 52429312 Sep 24 09:10 /u01/oradata/<sid>/standby_redo11a.rdo

-joe

Confidentiality Note: This message contains information that may be confidential and/or privileged. If you are not the intended recipient, you should not use, copy, disclose, distribute or take any action based on this message. If you have received this message in error, please advise the sender immediately by reply email and delete this message. Although ICAT Managers, LLC, Underwriters at Lloyd's, Syndicate 4242, scans e-mail and attachments for viruses, it does not guarantee that either are virus-free and accepts no liability for any damage sustained as a result of viruses. Thank you.

--
http://www.freelists.org/webpage/oracle-l
Received on Mon Sep 24 2012 - 10:16:32 CDT

Original text of this message