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