2018-05-02

Flashback Database After Failover: Correcting "Error ORA-38754: FLASHBACK DATABASE not started"


If the alert log file of the former primary DB contains the following error messages:
. . .
FLASHBACK DATABASE TO SCN 6693334
ORA-38754 signalled during: FLASHBACK DATABASE TO SCN 6693334...
. . .

Try to perform a flashback manually and you might get the following error:
SQL> FLASHBACK DATABASE TO SCN 6693334;
FLASHBACK DATABASE TO SCN 6693334
*
ERROR at line 1:
ORA-38754: FLASHBACK DATABASE not started; required redo log is not available
ORA-38762: redo logs needed for SCN 6691520 to SCN 6693334
ORA-38761: redo log sequence 124 in thread 1, incarnation 13 could not be accessed

In this case . . .

. . . on the new standby DB (former primary DB - before the failover),
use rman by connecting to the local DB and using the control file (NOCATALOG):
rman target=/ NOCATALOG

or (if baseenv from Triivadis is available - with history)

rmanh target=/ NOCATALOG

Since this command using the SCN did not return any archivelogs . . .
RMAN> LIST ARCHIVELOG SCN BETWEEN 6691520 AND 6693334;

. . . I searched for the backup of the archivelog with sequence 124 by guessing the time range . . .
LIST BACKUP OF ARCHIVELOG
      FROM TIME "TO_DATE('2018.05.01 20:00:00','YYYY.MM.DD HH24:MI:SS')"
      UNTIL TIME "TO_DATE('2018.05.02 12:00:00','YYYY.MM.DD HH24:MI:SS')";

. . . and was lucky and got the SCN of the desired archivelog (SCN 6691790) (but for restoring I choose the Low SCN of the previous archivelog i.e. 6689656 )
BS Key  Size       Device Type Elapsed Time Completion Time
------- ---------- ----------- ------------ -------------------
343     60.00M     SBT_TAPE    00:00:52     2018-05-02 10:57:31
        BP Key: 343   Status: AVAILABLE  Compressed: NO  Tag: TAG20180502T105639
        Handle: 6446830_C0200Z01_c9t1sib7_1_1   Media: V_3683633_19130778

  List of Archived Logs in backup set 343
  Thrd Seq     Low SCN    Low Time            Next SCN   Next Time
  ---- ------- ---------- ------------------- ---------- ---------
. . .
  1    122     6687465    2018-05-02 10:27:49 6689656    2018-05-02 10:42:47
  1    123     6689656    2018-05-02 10:42:47 6691790    2018-05-02 10:56:38
  1    124     6691790    2018-05-02 10:56:38 6691798    2018-05-02 10:56:38


HINT
It can happen, that the needed archivelog, belongs to another incarnation of the DB.
(If this is the case - on Oracle 12c - you can use the incarnation number with the rman restore statement.)
This statement list your incarnations.
RMAN> list incarnation;

List of Database Incarnations
DB Key  Inc Key DB Name  DB ID            STATUS  Reset SCN  Reset Time
------- ------- -------- ---------------- --- ---------- ----------
1       1       DB200Z01 2998214488       PARENT  1          2018-04-20 08:00:24
2       2       DB200Z01 2998214488       PARENT  2449245    2018-04-23 07:56:18
. . .
11      11      DB200Z01 2998214488       PARENT  5928815    2018-05-01 09:13:12
12      12      DB200Z01 2998214488       PARENT  6070931    2018-05-01 13:49:26
13      13      DB200Z01 2998214488       CURRENT 6179737    2018-05-01 14:47:30
==> Incarnation 13 is current (I do not need to use it with the restore statement)

Performing the restore of the archivelog (adapt the PARMS= for your needs):
RUN {
  ALLOCATE CHANNEL ch1 TYPE 'sbt_tape' PARMS="SBT_LIBRARY=/opt/hds/Base/libobk.so";
  # ALLOCATE CHANNEL ch1 TYPE disk;
  #
  RESTORE ARCHIVELOG FROM SCN 6689656;  # INCARNATION 13;
}

Output
allocated channel: ch1
channel ch1: SID=778 device type=SBT_TAPE
channel ch1: CommVault Systems for Oracle: Version 11.0.0(BUILD80)

Starting restore at 2018-05-02 13:15:52

archived log for thread 1 with sequence 125 is already on disk as file +U02/DB200Z01_HSB1/ARCHIVELOG/2018_05_02/thread_1_seq_125.759.975063515
. . .
archived log for thread 1 with sequence 133 is already on disk as file +U02/DB200Z01_HSB1/ARCHIVELOG/2018_05_02/thread_1_seq_133.741.975064009
channel ch1: starting archived log restore to default destination
channel ch1: restoring archived log
archived log thread=1 sequence=123
channel ch1: restoring archived log
archived log thread=1 sequence=124
channel ch1: reading from backup piece 6446830_DB200Z01_c9t1sib7_1_1

Now the standby DB should by able to automatically perform a flashback.

I hope it helps.

[ ]

No comments :

Post a Comment