Re: The Redo Hasn't Arrived Yet

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_at_yahoo.com> 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_at_gmail.com> 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_at_yahoo.com> 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_at_gmail.com> wrote:
>
>
> Why ABORT for the Standby ?
>
> I use SHUTDOWN IMMEDIATE.
>
> Hemant K Chitale
>
> On Mon, 18 May 2020, 22:11 Charlotte Hammond, <dmarc-noreply_at_freelists.org>
> 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 2020
> Standby crash recovery failed to bring standby database to a consistent
> point because needed redo hasn't arrived yet.
> MRP: Wait timeout: thread 1 sequence# 0
> Standby 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 unavailable
> Recovery interrupted!
> Some recovered datafiles maybe left media fuzzy
> Media recovery may continue but open resetlogs may fail
> Completed Standby Crash Recovery.
> Errors in file
> /u01/app/oracle/diag/rdbms/dinmybs1/DINMYBS1/trace/DINMYBS1_ora_4660.trc:
> ORA-10458: standby database requires recovery
> ORA-01196: file 1 is inconsistent due to a failed media recovery session
> ORA-01110: data file 1: '+DATA/dinmybs1/datafile/system.268.1023746733'
> ORA-10458 signalled during: ALTER DATABASE OPEN /* db agent *//* {0:0:2}
> */...
>
>
>

--
http://www.freelists.org/webpage/oracle-l