Re: The Redo Hasn't Arrived Yet

  • From: "Charlotte Hammond" <dmarc-noreply@xxxxxxxxxxxxx> (Redacted sender "charlottejanehammond" for DMARC)
  • To: Hemant K Chitale <hemantkchitale@xxxxxxxxx>
  • Date: Wed, 20 May 2020 08:08:50 +0000 (UTC)

 Thanks Hemant,
I don't issue any commands myself to start the database - it is started by 
Oracle Restart automatically.  The problem does not occur all the time but is 
quite frequent.   One thing I've noticed is that it's only on databases using 
active data guard where this happens - we don't get the problem on regular 
standby.
Unfortunately I don't have active data guard on any newer Oracle versions as 
the moment to compare with.
Just to re-iterate - I'm not too concerned about it as an operational issues as 
we can workaround pretty easily - I'm just more curious about why it's 
happening!
Thanks,Charlotte


    On Wednesday, May 20, 2020, 04:05:11 AM GMT+1, Hemant K Chitale 
<hemantkchitale@xxxxxxxxx> wrote:  
 
 
I just tested a 19c Standby database with SHUTDOWN ABORT wile transactions were 
in-flight.
The active datafiles appear in V$RECOVER_FILE for some time after the 
startup.But I don't see the messages you present.
What is the exact sequence of commands you issue to startup the standby 
database ?  At what point do these messages appear ?Do you have a 12c or higher 
standby that can be tested ?

Hemant K Chitale

Hemant K Chitale




On Tue, May 19, 2020 at 3:32 PM Charlotte Hammond 
<charlottejanehammond@xxxxxxxxx> wrote:

 Thanks Hemant,
But what I don't understand is how datafiles could be updated when the redo 
hasn't arrived yet.   Surely the redo should *always* be ahead of any other 
file in the database?
Thanks,Charlotte    On Tuesday, May 19, 2020, 02:58:14 AM GMT+1, Hemant K 
Chitale <hemantkchitale@xxxxxxxxx> wrote:  
 
 
imho, while applying redo to a Standby, datafiles will , temporarily, be at 
inconsistent SCNs until a checkpoint is done to update all the headers 
consistent with the controlfile.An ABORT doesn't execute a checkpoint while an 
IMMEDIATE does do so.

Hemant K Chitale




On Mon, May 18, 2020 at 11:24 PM Charlotte Hammond 
<charlottejanehammond@xxxxxxxxx> wrote:

 I agree - shutdown immediate would be better.
It's kind of procedural - servers are being shutdown by a third party "at 
random" when not required to save on hosting costs - Oracle Restart is being 
used which uses shutdown abort when the host itself is going down (regardless 
of the shutdown mode specified for the resource).   
Now, there are various ways this can be fixed but I'm really trying to 
understand WHY this is actually causing the problem below, so I can explain / 
motivate people to address it.
Thanks!Charlotte
    On Monday, May 18, 2020, 03:38:39 PM GMT+1, Hemant K Chitale 
<hemantkchitale@xxxxxxxxx> wrote:  
 
 Why ABORT for the Standby ?
I use SHUTDOWN IMMEDIATE.
Hemant K Chitale
On Mon, 18 May 2020, 22:11 Charlotte Hammond, <dmarc-noreply@xxxxxxxxxxxxx> 
wrote:

Hello,
If we shutdown *abort* our Data Guard standbys (11.2.0.4 maximum performance 
with RTA), we occasionally get the errors below on restart ("redo hasn't 
arrived yet")
Now this isn't a problem and is easy to fix - but I'm trying to understand WHY 
it happens:  How can the controlfile and/or datafile headers in the standby 
database be ahead of the available redo at the time of abort?i.e. What is 
different about crash recovery on a standby compared to a primary?
Many thanks for any clarifications!
Charlotte

Mon May 18 07:03:53 2020Standby crash recovery failed to bring standby database 
to a consistentpoint because needed redo hasn't arrived yet.MRP: Wait timeout: 
thread 1 sequence# 0Standby Crash Recovery aborted due to error 16016.Errors in 
file 
/u01/app/oracle/diag/rdbms/dinmybs1/DINMYBS1/trace/DINMYBS1_ora_4660.trc:ORA-16016:
 archived log for thread 1 sequence# 1134 unavailableRecovery interrupted!Some 
recovered datafiles maybe left media fuzzyMedia recovery may continue but open 
resetlogs may failCompleted Standby Crash Recovery.Errors in file 
/u01/app/oracle/diag/rdbms/dinmybs1/DINMYBS1/trace/DINMYBS1_ora_4660.trc:ORA-10458:
 standby database requires recoveryORA-01196: file 1 is inconsistent due to a 
failed media recovery sessionORA-01110: data file 1: 
'+DATA/dinmybs1/datafile/system.268.1023746733'ORA-10458 signalled during: 
ALTER DATABASE OPEN /* db agent *//* {0:0:2} */...


  
  
  

Other related posts: