Re: Applying logs to standby in 11g
- From: David Fitzjarrell <oratune@xxxxxxxxx>
- To: "sbecker6925@xxxxxxxxx" <sbecker6925@xxxxxxxxx>, oracle-l <oracle-l@xxxxxxxxxxxxx>
- Date: Mon, 22 Oct 2012 12:05:00 -0700 (PDT)
Is this 11.2.0.3? If so there is a new wrinkle to the redo mechanism --
adaptive log file sync which uses foreground processes to 'poll' to see if the
commit is complete, rather than using semaphores as earlier releases did. The
semaphore route is still available in 11.2.0.3 and Oracle can switch between
the two based on load and response time.
This may explain the discrepancy you're seeing with v$archive_log 'reporting'
log apply.
David Fitzjarrell
________________________________
From: Sandra Becker <sbecker6925@xxxxxxxxx>
To: oracle-l <oracle-l@xxxxxxxxxxxxx>
Sent: Monday, October 22, 2012 12:32 PM
Subject: Applying logs to standby in 11g
This pas weekend I upgraded my production OLTP from 10g to 11g (SUSE11 on
IBM zLinux), then I created an 11g standby. We moved the database to
newer, faster, correctly configured storage at the same time. All went
well and everything is functioning better than it did before the upgrade.
My question is regarding the value in the applied column of v$archived_log.
Under 10g the value was changed to 'YES' within a few minutes, or less,
for smaller logs such as less than 1M. Under 11g I don't see that changing
until a log switch so it appears I am a log behind. I can see the messages
that media recover has started for one log followed by a message that
another log is in transit so I am assuming that the first log has been
successfully applied, but v$archived_log still shows it isn't applied.
Perhaps that's not a valid assumption.
.
.
.
Media Recovery Log /u06/oradata/prod/arch/1_304_797150180.arc
Media Recovery Waiting for thread 1 sequence 305 (in transit)
Question: Is this normal behavior in 11g? If not, where should I look to
see what the cause is? I've been searching MOS and Google but haven't seen
this scenario addressed yet.
Thanks in advance.
--
Sandy
Transzap, Inc.
--
//www.freelists.org/webpage/oracle-l
--
//www.freelists.org/webpage/oracle-l
Other related posts:
