Re: data guard real time apply question

From: Vamshi Damidi <dbaprimatics_at_gmail.com>
Date: Wed, 3 Oct 2012 07:33:56 -0400
Message-ID: <CAKshVhzauC_io_LDXJtJOZ2=gkgQzB==1wrTqa6i-Tq_-nfTEw_at_mail.gmail.com>



Hi J,
1. primary LGWR uses Oracle Net to talk to standby RFS (remote file server)
I believe this is LNS
2. standby RFS writes redo data to standby online redo logs archived redo is just transfered to standby server to location of archive_log_dest location on stadby database, and you can do this manually too
3. standby online redo logs are applied to standby database using MRP (media/managed recovery process?)
yes its recovery process through which archived logs from location of archive_log_dest are being applied

standby logs used for mainly ( both on active and standby databases ) active syn process and you are using async and only used by active database and you create them on standby database for configuration purposes to make sure the functionality is same when you make standby database an active database

I hope i gave correct answer but please refer to documentation once again since its been long time i configure Dataguard.

Thanks,
Vamshi .D

On Fri, Sep 21, 2012 at 12:22 PM, Sweetser, Joe <JSweetser_at_icat.com> wrote:

> I am a little confused.
> 11.2.0.2
> Red Hat Linux 5.6
> Physical standby database
> Real time apply
> Archive_dest_state_2 = SERVICE=<sid>_stby NOAFFIRM ASYNC
> VALID_FOR=(ALL_LOGFILES, PRIMARY_ROLE) DB_UNIQUE_NAME=<sid>_stby
>
> Basic question is where does Oracle actually write the redo data on the
> standby side of the configuration? I would expect the timestamps on the
> standby redo logs to be current and/or match what I am seeing in the alert
> log but that is not the case.
>
> If I understand the theory here (greatly simplified):
>
>
> 1. primary LGWR uses Oracle Net to talk to standby RFS (remote file
> server)
>
> 2. standby RFS writes redo data to standby online redo logs
>
> 3. standby online redo logs are applied to standby database using
> MRP (media/managed recovery process?)
>
> Everything appears to be working correctly and I can see transactions
> applied to the standby as they occur on the primary by tailing the standby
> alert log as shown here:
>
> Fri Sep 21 09:32:16 2012
> Archived Log entry 3263 added for thread 1 sequence 82669 rlc 765739491 ID
> 0xb1c714a3 dest 2:
> RFS[15]: No standby redo logfiles created for thread 1
> RFS[15]: Opened log for thread 1 sequence 82670 dbid -<whatever> branch
> 765739491
> Fri Sep 21 09:32:17 2012
> Media Recovery Log <full_path_to_archive_log_file>_1_82669_765739491.arc
> Media Recovery Waiting for thread 1 sequence 82670 (in transit)
> Archived Log entry 3264 added for thread 1 sequence 82670 rlc 765739491 ID
> 0xb1c714a3 dest 2:
> RFS[15]: No standby redo logfiles created for thread 1
> RFS[15]: Opened log for thread 1 sequence 82671 dbid -<whatever> branch
> 765739491
> Media Recovery Log <full_path_to_archive_log_file>_1_82670_765739491.arc
> Media Recovery Waiting for thread 1 sequence 82671 (in transit)
> Fri Sep 21 09:50:05 2012
> Archived Log entry 3265 added for thread 1 sequence 82671 rlc 765739491 ID
> 0xb1c714a3 dest 2:
> RFS[15]: No standby redo logfiles created for thread 1
> RFS[15]: Opened log for thread 1 sequence 82672 dbid -<whatever> branch
> 765739491
> Fri Sep 21 09:50:05 2012
> Media Recovery Log <full_path_to_archive_log_file>_1_82671_765739491.arc
> Media Recovery Waiting for thread 1 sequence 82672 (in transit)
>
> Long listing of the standby redo logs:
>
> ls -lart /u0*/oradata/<sid>/*rdo
> <snip> 52429312 Sep 5 12:59 <full_path_to>/online_redo01.rdo
> <snip> 52429312 Sep 5 12:59 <full_path_to>/online_redo02.rdo
> <snip> 52429312 Sep 5 12:59 <full_path_to>/online_redo03.rdo
>
> Sep 5 12:59 is when the standby database was last started.
>
> Is there a reason why the modification times of the standby redo log files
> are not updated? Is Oracle actually writing to those files?
>
> Thanks for any/all insight,
> -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
>
>
>

--
http://www.freelists.org/webpage/oracle-l
Received on Wed Oct 03 2012 - 13:33:56 CEST

Original text of this message