Re: One primary with two physical standbys exhibiting different behavior with regard to lag

  • From: Neil Chandler <neil_chandler@xxxxxxxxxxx>
  • To: Sandra Becker <sbecker6925@xxxxxxxxx>, John Thomas <jt2354@xxxxxxxxx>
  • Date: Fri, 4 Jan 2019 10:11:27 +0000

Sandy,

So if you do a manual "alter system archive log current" on the Primary, it 
catches up?

I would look at the config parameters to compare the configuration. Could you 
share the configuration info (db/server names suitably redacted):

dgmgrl> show configuration verbose
dgmgrl> show database verbose <primary|standby2|standby2>


regards

Neil Chandler
Database Guy, Knows Things.
________________________________
From: Sandra Becker <sbecker6925@xxxxxxxxx>
Sent: 03 January 2019 22:49
To: John Thomas
Cc: Andrew Kerber; Neil Chandler; oracle-l
Subject: Re: One primary with two physical standbys exhibiting different 
behavior with regard to lag

My understanding is the network setup is the same between the standbys.   I 
didn't look at the network right away.  :-)   I made the changes suggested by 
Neil, but I'm still seeing the delay.  Before I did a manual log switch, the 
delay was over 30 minutes.  Not good for this critical production standby.

Sandy

On Thu, Jan 3, 2019 at 3:36 PM John Thomas 
<jt2354@xxxxxxxxx<mailto:jt2354@xxxxxxxxx>> wrote:
There's no excessive delay between your primary and the lagging standby is 
there? Smaller pipe? Lots of network retries?

Probably the second thing you checked...

Regards,

John

On Thu, 3 Jan 2019 at 22:10, Sandra Becker 
<sbecker6925@xxxxxxxxx<mailto:sbecker6925@xxxxxxxxx>> wrote:
Thanks, Andrew.  That's one of the first things I checked.  It's the same on 
both standbys.

Sandy

On Thu, Jan 3, 2019 at 2:47 PM Andrew Kerber 
<andrew.kerber@xxxxxxxxx<mailto:andrew.kerber@xxxxxxxxx>> wrote:
Neil most likely spotted the problem.  But you should also check to make sure 
that the protection mode is the same on both standbys.If the instance that is 
behind is using the maximum performance (async) mode it can run a ways behind 
the primary.

On Thu, Jan 3, 2019 at 3:36 PM Neil Chandler 
<neil_chandler@xxxxxxxxxxx<mailto:neil_chandler@xxxxxxxxxxx>> wrote:
Sandy,

Have you checked the Standby Redo logs? There's a slight (annoying) change in 
Oracle 12.1 onwards which means that Standby Redo logs get created with Thread 
0 instead of Thread 1 by default (for a single instance database). Redo can 
only use Standby Redo when the threads are the same. If this is RAC you need 
Standby Redo for each thread - and you must have 1 more Standby Redo than 
Online Redo for each thread.

By coincidence, I wrote a blog post about this 10 minutes ago.

https://chandlerdba.com/2019/01/03/data-guard-unexpected-lag/

regards

Neil Chandler
Database Guy. Knows Things.

________________________________
From: oracle-l-bounce@xxxxxxxxxxxxx<mailto:oracle-l-bounce@xxxxxxxxxxxxx
<oracle-l-bounce@xxxxxxxxxxxxx<mailto:oracle-l-bounce@xxxxxxxxxxxxx>> on behalf 
of Sandra Becker <sbecker6925@xxxxxxxxx<mailto:sbecker6925@xxxxxxxxx>>
Sent: 03 January 2019 20:29
To: oracle-l
Subject: One primary with two physical standbys exhibiting different behavior 
with regard to lag

Oracle 12.1.0.2
RHEL7

To begin with, I have not worked much at all with standby databases, so my 
knowledge is somewhat lacking.

For business reasons, we have a primary database with two physical standbys.  
Everything is configured in dgmgrl and enabled.  Monitoring with EM13c is 
reporting the lag times, so all looks good for basic setup and monitoring.  We 
seem to have significant lag at times on one of the standbys, as much as 20 
minutes.  When looking at v$managed_standby, we see the status as 
"WAIT_FOR_LOG".   The other standby never seems to be more that a few seconds 
behind, if at all, and the status is "APPLYING_LOG".

Is this normal?  I've been researching, but haven't found an answer yet.  I 
didn't create or start the standby databases, so I don't have any idea what was 
actually done that could be causing this behavior.  Any suggestions would be 
appreciated.

Thank you,

--
Sandy B.



--
Andrew W. Kerber

'If at first you dont succeed, dont take up skydiving.'


--
Sandy B.



--
Sandy B.

Other related posts: