RE: data guard real time apply question
- From: "Sweetser, Joe" <JSweetser@xxxxxxxx>
- To: "pawel.smolarz@xxxxxxxxxx" <pawel.smolarz@xxxxxxxxxx>, "mdinh235@xxxxxxxxx" <mdinh235@xxxxxxxxx>, April Sims <aprilcsims@xxxxxxxxx>, "jack.van.zanen@xxxxxxxxx" <jack.van.zanen@xxxxxxxxx>
- Date: Mon, 24 Sep 2012 15:16:32 +0000
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.
--
//www.freelists.org/webpage/oracle-l
Other related posts:
