RESOLVING ARCHIVE GAP BETWEEN PRIMARY & STANDBY

DATBASE

Oracle DBA Technology Explored byGunasekaran , Thiyagu

ARCHIVE GAP
An archive gap means, a set of archived redo logs that could not be transmitted to
theStandby site from the Primary database. Mostly this problem occurs the
network connectivitybecomes unavailable between the Primary and Standby site.
When the network is availablea gain Data Guard resumes redo data transmission
from the Primary to Standby site. OracleDG provides 2 methods for
GAP resolution. They are
AUTOMATIC
and
FAL
.

Automatic Gap Resolution

&

FAL Gap Resolution

Lets consider an extended n/w failure occurred between the Primary and Standby
machines
which causes the Standby is very far behind the Primary database, then an RMAN
INCREMENTALBACKUP can be used to roll the Standby database forward faster
than redo log apply.When the archived logs are missing on the Standby database,
simply we can ship missing logsfrom the Primary to Standby database; (If missing
logs are very less count e.g. (below 15).We need to register all Shipped logs in the
Standby database so that Gap can be resolved.In this article I will demonstrate how
to resolve archive log gaps using following methods.

Manually resolving a Gap (by Shipping logs from Primary to Standby)

To Roll Forward a Standby database using RMAN Incremental backup.

DISASTER RECOVERY CONFIGURATION

Primary Database 192.168.222.131 DEV Database ServerStandby Database 192.16

8.222.132 UAT Database ServerPrimary database db_unique_name crmsStandby d
atabase db_unique_name stbycrms
MANUALLY RESOLVING GAPS

# On Primary databaseSYS> select name, db_unique_name, database_role

from v$database; NAME DB_UNIQUE_NAME DATABASE_ROLE
--------- ------------------------------ ----------------CRMS crms
PRIMARY

# On Standby databaseSYS> select name, db_unique_name, database_role

from v$database; NAME DB_UNIQUE_NAME DATABASE_ROLE OPEN_
MODE
--------- ------------------------------ ---------------- ------------CRMS stbycrms
PHYSICAL STANDBY

MOUNTED

# On Primary databaseSYS> select thread#, max(sequence#) from

v$archived_log group by thread#;THREAD# MAX(SEQUENCE#)---------- ---
-----------
1 551
# On Standby databaseSYS> select thread#, max(sequence#)
from v$archived_log where applied='YES' group by thread#;THREAD#
MAX(SEQUENCE#)-------1--- --------------
1 551
# Standby database is waiting for SEQ# 552SYS> select process,
sequence#, status from
v$managed_standby;PROCESS SEQUENCE# STATUS
--------- ---------- ------------ARCH 551 CLOSING
ARCH 558 CLOSING
ARCH 0 CONNECTEDARCH 0 CONNECTEDRFS 0 IDLERFS 0 IDLERFS 559
IDLERFS 0 IDLE
MRP0 552 WAIT_FOR_GAP
9 rows selected.
# Snippet of Standby alert log$ cd
/u01/app/oracle/diag/rdbms/stbycrms/stbycrms/trace$ tail -f
alert_stbycrms.log
Fetching gap sequence in thread 1, gap sequence 552-556.....FAL[client]: Failed to
request gap sequence
GAP - thread 1 sequence 552-556
DBID 1613387466 branch 913081878FAL[client]: All defined FAL servers have
been attempted.
RESOLVING ARCHIVE GAP BETWEEN PRIMARY
&
STANDBY DATBASE
Oracle DBA Technology Explored byGunasekaran , Thiyagu
DETECTING GAPS
Oracle Data Guard provide us with a simple view
(v$archive_gap)
to detect a gap.
On Standby databaseSYS> select * from v$archive_gap;THREAD#
LOW_SEQUENCE# HIGH_SEQUENCE#
---------- ------------- --------------1
552 556
Output of Standby database is currently missing log files from sequence#
552 to 556;
theStandby database is 5 logs behind the Primary database.
ORACLE NOTE:
Refer
BUG #10072528
V$ARCHIVE_GAP may not detect archive gap when Physical Standby is open
read only.
FIND ARCHIVE LOGS AT PRIMARY SERVER
After identifying a gap (as shown above), as a DBA you need to query the primary
databaseto locate the archived redo logs on the primary database. I have configured
the localarchive destination on primary is
LOG_ARCHIVE_DEST_1.

# On Primary database (SEQUENCE 552 to 556)SYS> select nameFROM

v$archived_log WHERE thread# = 1 AND dest_id = 1 AND sequence#
BETWEEN 552 and 556; NAME
--------------------------------------------------------------------------------------
/u01/app/oracle/flash_recovery_area/CRMS/archivelog/2016_06_01/o1_mf_1_552
_cnvodqq5_.arc/u01/app/oracle/flash_recovery_area/CRMS/archivelog/2016_06_0
1/o1_mf_1_553_cnvohcy1_.arc/u01/app/oracle/flash_recovery_area/CRMS/archiv
elog/2016_06_01/o1_mf_1_554_cnvokk6z_.arc/u01/app/oracle/flash_recovery_are
a/CRMS/archivelog/2016_06_01/o1_mf_1_555_cnvom1l4_.arc/u01/app/oracle/fla
sh_recovery_area/CRMS/archivelog/2016_06_01/o1_mf_1_556_cnvomxkz_.arc
Copy the above redo log files to the Physical Standby database and register
them using the
ALTER DATABASE REGISTER LOGFILE ... SQL statement
on the Physical Standby database.
COPY ARCHIVELOG FILES TO STANDBY
$ ls /u01/app/oracle/flash_recovery_area/CRMS/archivelog/2016_06_01/
o1_mf_1_553_cnvohcy1_.arc o1_mf_1_555_cnvom1l4_.arc
o1_mf_1_552_cnvodqq5_.arco1_mf_1_554_cnvokk6z_.arc
o1_mf_1_556_cnvomxkz_.arc
;
SYS> alter database register
logfile '/u01/app/oracle/flash_recovery_area/STBYCRMS/archivelog/2016_06
_01/o1_mf_1_552_cnvodqq5_.arc';
Database altered.
SYS> alter database register
logfile '/u01/app/oracle/flash_recovery_area/STBYCRMS/archivelog/2016_06
_01/

o1_mf_1_553_cnvohcy1_.arc';
Database altered.
.
SYS> alter database register
logfile '/u01/app/oracle/flash_recovery_area/STBYCRMS/archivelog/2016_06
_01/o1_mf_1_554_cnvokk6z_.arc';
Database altered.
SYS> alter database register
logfile '/u01/app/oracle/flash_recovery_area/STBYCRMS/archivelog/2016_06
_01/o1_mf_1_555_cnvom1l4_.arc';
Database altered.
SYS> alter database register
logfile '/u01/app/oracle/flash_recovery_area/STBYCRMS/archivelog/2016_06
_01/o1_mf_1_556_cnvomxkz_.arc';
Database altered.Recovery process would start automatically or else stop
the managed recovery process (MRP)and re-start it once again;
thats it!

WHY WE NEED TO REGISTER ARCHIVE LOGS AT STANDBY ?

On Primary to Standby Server, archive logs were not transferred by the log transfer
service,(but through SCP) so the managed recovery process will not have any info
about these logs.Then manually transferred logs need to be registered with the
managed recovery processbefore they applied by the log apply service.
CHECK WITH FOLLOWING QUERIES
SQL> archive log list;SQL> select max(sequence#) from v$archived_log;SQL>
select sequence#, archived, applied from v$archived_logwhere applied='YES'
order by 1;This is simple way to handle manually Resolving Gaps.

ROLL FORWARD PHYSICAL STANDBY USING RMAN

INCREMENTAL BACKUP
The Standby database lags far behind from the Primary database then i noticed that
thereis a huge sequence mismatch between Primary & Standby database. There
could be some reasons.

Network unavailable between Primary and Standby database.

Archive logs
deleted/corrupted
on Primary database.In cases where a Physical Standby database is out of Sync
with Primary database. In caseof archive logs are missing/corrupt we have to
rebuild the Standby from scratch. If thedatabase size in
terabytes
again rebuilding the Standby database could be a tedious job;but we a solution
to resolve this kind of issues.As a DBA you can go for an RMAN Incremental
backup to sync a Physical Standby with thePrimary database; using the command
RMAN BACKUP INCREMENTAL FROM SCN

create a backup onthe P

rimary database that starts at the standby databases current SCN, which can
then be
used to roll the Standby database forward in time.Please assume bunch of archive
logs are deleted/corrupted on the Primary database Serverbefore they are
transferring to the Standby database Server. In this case, I demonstratean efficient
way to Sync Standby with Primary (an alternative to rebuild the Standby DB)!
DISASTER RECOVERY
11
g
DATABASE SERVER FOR PRIMARY 192.168.222.133 DB_UNIQUE_NAME
CRMS11g DATABASE SERVER FOR STANDBY 192.168.222.134 DB_UNIQ
UE_NAME STBYCRMSOracle Database Software Version is 11.2.0.1.0 on
OEL(5.5)
# On Primary databaseSYS> select name, db_unique_name, database_role
from v$database; NAME DB_UNIQUE_NAME DATABASE_ROLE
--------- ------------------------------ ----------------CRMS crms
PRIMARY

# On Standby databaseSYS> select name, db_unique_name, database_role,

open_mode from
v$database; NAME DB_UNIQUE_NAME DATABASE_ROLE OPEN_MOD
E
--------- ------------------------------ ---------------- --------------------CRMS stbycrms
PHYSICAL STANDBY MOUNTED# On Primary database (CaptureSYS>
select thread#, max(sequence#) from v$archived_log group by
thread#;THREAD# MAX(SEQUENCE#)
---------- --------------1
653

# On Standby databaseSYS> select thread#, max(sequence#)

from v$archived_log where applied='YES' group by thread#;THREAD#
MAX(SEQUENCE#)
---------- --------------1
558
Note the difference, On Standby last applied SEQUENCE#
558
but on Primary SEQUENCE#
653# Finding Archive Gap SEQ# at Standby databaseSYS> select * from
v$archive_gap;THREAD# LOW_SEQUENCE# HIGH_SEQUENCE#
---------- ------------- --------------1
559

644SYS>@archive_gap.sql DB_NAME HOSTNAME LOG_ARCHIVED LO

G_APPLIED APPLIED_TIME LOG_GAP
---------- -------------- ------------ ----------- -------------- -------CRMS OEL5
653

558
 01-JUN/04:33 95
CANCEL MANAGED RECOVERY PROCEES
# On Standby databaseSYS> alter database recover managed standby
database cancel;
Database altered.
GET LAST SCN OF THE STANDBY DATABASE
Last SCN of the
STANDBY,
will be used for the RMAN Incremental backup at Primary DB Server.
# On the Standby database Server (Checking last SCN of the Standby)SYS>
select current_scn from v$database;CURRENT_SCN
-----------3473651
# On the Primary database Server (Capture current_scn at primary)SYS>
select current_scn from v$database;CURRENT_SCN
-----------4538393Note the SCN DIFFERENCE 4538393

3473651

=
1064742
(Now the Standby is lag behind).

But I want to know how long the Standby database is far behind in terms of
(hours/days).To know that I used the
scn_to_timestamp
function to translate the SCN to timestamp.
# On Primary databaseSYS> select scn_to_timestamp(4538393) from
dual;SCN_TO_TIMESTAMP(4538393)
---------------------------------------01-JUN-16
11.12.52.000000000 PM

# I execute following SQL

S
tatement at Primary database (NOT workable at Standby)SYS> select
scn_to_timestamp(3473651) from dual;SCN_TO_TIMESTAMP(3473651)
--------------------------------------------------01-JUN-16
04.32.44.000000000 AM
The Standby database
far behind more than 18 hours
from the Primary database.
 NOTE
:
Query NOT WORKABLE in OPEN READ ONLY MODE or MOUNTED
MODE.

CHECKING ARCHIVE LOGS AT PRIMARY

$ ls /u01/app/oracle/flash_recovery_area/CRMS/archivelog/2016_06_01/o1_mf
_1_645_cnxo02c4_.arc
o1_mf_1_647_cnxo9ndy_.arc
o1_mf_1_649_cnxoc4d6_.arco1_mf_1_651_cnxpl4fd_.arc
o1_mf_1_653_cnxpyh0c_.arc
o1_mf_1_646_cnxo2329_.arco1_mf_1_648_cnxob5cl_.arc
o1_mf_1_650_cnxp29x7_.arc o1_mf_1_652_cnxpyd51_.arcTo Sync Standby with
Primary we need archive logs SEQUENCE# 559 to SEQUENCE# 644. But
thesearchives are NOT found at Primary Site; then only choice is
RMAN
Incremental backup.
# Shutdown the Standby databaseSYS> shutdown immediate;
...On the Primary, take an Incremental backup from the
SCN#

(3473651)
of the Standby database.The last recorded SCN#
(3473651)
of the

Standby database.
# Connect target as Primary database$ rman target sys/passwd@CRMSDB
..connected to target database: CRMS (DBID=1613387466)
RMAN> backup incremental from SCN 3473651 database
format '/u03/rman-bkp/stby_%U'TAG='FOR_STBY';
Starting backup at 02-JUN-16using target database control file instead of recovery
catalogallocated channel: ORA_DISK_1channel ORA_DISK_1: SID=52 device
type=DISKbackup will be obsolete on date 09-JUN-16archived logs will not be
kept or backed upchannel ORA_DISK_1: starting full datafile backup setchannel
ORA_DISK_1: specifying datafile(s) in backup setinput datafile file
number=00003 name=/u01/app/oracle/oradata/crms/undotbs01.dbfinput datafile
file number=00004 name=/u01/app/oracle/oradata/crms/users01.dbfinput datafile
file number=00001 name=/u01/app/oracle/oradata/crms/system01.dbfinput datafile
file number=00002 name=/u01/app/oracle/oradata/crms/sysaux01.dbfinput
datafile file
number=00005 name=/u01/app/oracle/oradata/crms/example01.dbfinput datafile
file number=00007 name=/u01/app/oracle/oradata/crms/users02.dbfinput datafile
file number=00006 name=/u01/app/oracle/oradata/crms/users03.dbfinput datafile
file number=00008 name=/u01/app/oracle/oradata/crms/mytbs01.dbfchannel
ORA_DISK_1: starting piece 1 at 02-JUN-16channel ORA_DISK_1: finished
piece 1 at 02-JUN-16
piece handle=/u03/rman-bkp/
stby_03r73ftc_1_1
tag=FOR_STBY comment=NONEchannel ORA_DISK_1: backup set complete,
elapsed time: 00:13:13using channel ORA_DISK_1backup will be obsolete on
date 09-JUN-16archived logs will not be kept or backed upchannel ORA_DISK_1:
starting full datafile backup setchannel ORA_DISK_1: specifying datafile(s) in
backup set
including current control file in backup set
channel ORA_DISK_1: starting piece 1 at 02-JUN-16channel ORA_DISK_1:
finished piece 1 at 02-JUN-16piece handle=/u03/rman-bkp/
stby_04r73gm6_1_1
tag=FOR_STBY comment=NONEchannel ORA_DISK_1: backup set complete,
elapsed time: 00:00:04Finished backup at 02-JUN-16
CREATE A NEW STANDBY CONTROLFILE
On the Primary database, create a new Standby control file.We can use (SQL*Plus
or RMAN) to create a Standby control file; Anyone method is enough.
SYS> alter database create standby controlfile as '/home/oracle/stdb_ctrl.ctl';
Database altered.
Or

# Connect target as Primary

&
Create control file backup for Standby databaseRMAN> backup current
controlfile for standby format '/u03/rman-bkp/stdb_ctrl.ctl';
Starting backup at 02-JUN-16using channel ORA_DISK_1channel ORA_DISK_1:
starting full datafile backup setchannel ORA_DISK_1: specifying datafile(s) in
backup setincluding standby control file in backup setchannel ORA_DISK_1:
starting piece 1 at 02-JUN-16channel ORA_DISK_1: finished piece 1 at 02-JUN-
16piece handle=/u03/rman-bkp/
stdb_ctrl.ctl
tag=TAG20160602T024937 comment=NONEchannel ORA_DISK_1: backup set
complete, elapsed time: 00:00:01Finished backup at 02-JUN-16
LISTING CREATED BACKUP SETS
$ ls -l /u03/rman-bkp/
total 4707832-rw-r----- 1 oracle oinstall
4792238080
Jun 2 02:42 stby_03r73ftc_1_1-rw-r-----
1 oracle oinstall 11927552 Jun 2 02:42 stby_04r73gm6_1_1-rw-r-----
1 oracle oinstall 11927552 Jun 2 02:49 stdb_ctrl.ctl

RESOLVING ARCHIVE GAP BETWEEN PRIMARY

&
STANDBY DATBASE
Oracle DBA Technology Explored byGunasekaran , Thiyagu
TRANSFER BACKUP SETS TO STANDBY SERVER
Using OS utility to transfer these backups to the Standby Server from Primary
Server.
# SCP all backup sets to the Standby Server at Primary Server$ scp
*oracle@192.168.222.134:/u03/bkp/
oracle@192.168.222.134's password:
******stby_03r73ftc_1_1 100% 4570MB 2.4MB/s 31:43stby_04r73gm6_1_1 100
% 11MB 5.7MB/s 00:02stdb_ctrl.ctl 100% 11MB 2.8MB/s 00:04
VERIFY RECEIVED BACKUP SETS ON THE STANDBY SERVER
$ ls -l /u03/bkp/
total 4707832-rw-r----- 1 oracle oinstall 4792238080 Jun 2
05:40 stby_03r73ftc_1_1-rw-r-----
1 oracle oinstall 11927552 Jun 2 05:40 stby_04r73gm6_1_1-rw-r-----
1 oracle oinstall 11927552 Jun 2 05:40 stdb_ctrl.ctlNote the location of all
data files
&
Control file(s) at the Standby Database Server.
SYS> startup mount;SYS> spool datafile_names.txtSYS> set lines 100;SYS>
column name format a100;SYS> show parameter control_files;SYS> select
count(*) from v$datafile;SYS> select file#, name from v$datafile order
by file#;SYS> spool offSYS> shut immediate;SYS> ! cat datafile_names.txt
RELOCATE EXISTING CONTROL FILES
# Renamed old control files at Standby Server$
cd /u01/app/oracle/flash_recovery_area/stbycrms/
$
mv control02.ctl /tmp/control02.ctl.bkp
$
cd /u01/app/oracle/oradata/stbycrms/
$
mv control01.ctl /tmp/control01.ctl.bkp
NOTE:
If you do not want rename control files, you can remove these files at OS level.
BRINGUP THE STANDBY INSTANCE

NOMOUNT PHASE
$ export ORACLE_SID=stbycrms$ rman target /
connected to target database (not started)
RMAN> startup nomount;
Oracle instance
startedTotal System Global Area 912306176 bytesFixed Size 1340244 bytesVariab
le Size 536874156 bytesDatabase Buffers 369098752 bytesRedo Buffers 4993024
bytes
# Restore Standby control files from the backup# Replacing newly created
controlfile with old filesRMAN> restore standby controlfile
from '/u03/bkp/stdb_ctrl.ctl';
Starting restore at 02-JUN-16allocated channel: ORA_DISK_1channel
ORA_DISK_1: SID=19 device type=DISKchannel ORA_DISK_1: restoring
control filechannel ORA_DISK_1: restore complete, elapsed time: 00:00:03
output file name=/u01/app/oracle/oradata/stbycrms/control01.ctloutput file na
me=/u01/app/oracle/flash_recovery_area/stbycrms/control02.ctl
Finished restore at 02-JUN-16
SHUTDOWN THE STANDBY DATABASE
&
STARTUP MOUNT
RMAN> shutdown immediate;
Oracle instance shut down
# Startup the database with new controlfileRMAN> startup mount;
connected to target database (not started)Oracle instance starteddatabase mounted

Total System Global Area 912306176 bytes.....

CATALOG THE INCREMENTAL BACKUP FILES AT STANDBY
RMAN does not know about these backup sets. We must catalog the new backup
sets on theStandby database. I.e. when we register these backup files to the
Standby database controlfile with
RMAN CATALOG
 command, the Standby control file gets updated about these backupfiles. It helps
to recover the Standby using these RMAN backup files.
# REGISTERING BACKUP SETSRMAN> catalog start with '/u03/bkp';
Starting implicit crosscheck backup at 02-JUN-16allocated channel:
ORA_DISK_1channel ORA_DISK_1: SID=18 device type=DISKCrosschecked 3
objectsFinished implicit crosscheck backup at 02-JUN-16Starting implicit
crosscheck copy at 02-JUN-16using channel ORA_DISK_1Crosschecked 2
objectsFinished implicit crosscheck copy at 02-JUN-16searching for all files in the
recovery areacataloging files...cataloging doneList of Cataloged
Files=======================
File
Name:/u01/app/oracle/flash_recovery_area/STBYCRMS/archivelog/2016_06_01/
o1_mf_1_
646
_cnxof4nl_.arcFile
Name:/u01/app/oracle/flash_recovery_area/STBYCRMS/archivelog/2016_06_01/
o1_mf_1_
647
_cnxocnkr_.arcFile
Name:/u01/app/oracle/flash_recovery_area/STBYCRMS/archivelog/2016_06_01/
o1_mf_1_
652
_cnxpz1lz_.arcFile
Name:/u01/app/oracle/flash_recovery_area/STBYCRMS/archivelog/2016_06_01/
o1_mf_1_
645
_cnxodgj5_.arcFile
Name:/u01/app/oracle/flash_recovery_area/STBYCRMS/archivelog/2016_06_01/
o1_mf_1_
651
_cnxodqq5_.arcFile
Name:/u01/app/oracle/flash_recovery_area/STBYCRMS/archivelog/2016_06_01/
o1_mf_1_
650
_cnxp48lh_.arcFile
Name:/u01/app/oracle/flash_recovery_area/STBYCRMS/archivelog/2016_06_01/
o1_mf_1_
649
_cnxoc5oq_.arcFile
Name:/u01/app/oracle/flash_recovery_area/STBYCRMS/archivelog/2016_06_01/
o1_mf_1_
653
_cnxpzpvs_.arcFile
Name:/u01/app/oracle/flash_recovery_area/STBYCRMS/archivelog/2016_06_01/
o1_mf_1_
648
_cnxobwyc_.arc
searching for all files that match the pattern /u03/bkpList of Files Unknown to
the Database=====================================File
Name: /u03/bkp/stby_04r73gm6_1_1File Name: /u03/bkp/stby_03r73ftc_1_1File
Name: /u03/bkp/stdb_ctrl.ctlDo you really want to catalog the above files (enter
YES or NO)?
Y
cataloging files...cataloging doneList of Cataloged
Files=======================File Name: /u03/bkp/stby_04r73gm6_1_1File
Name: /u03/bkp/stby_03r73ftc_1_1File Name: /u03/bkp/stdb_ctrl.ctl
APPLY INCREMENTAL BACKUP TO THE STANDBY DATABASE
The recovery process will use cataloged incremental backup sets because we have
registered.This backup taken for Physical Standby DB Sync;
noredo
key word is required. Check
here

# Recover the database with Catalog incremental backup setsRMAN> recover

database noredo;
Starting recover at 02-JUN-16using channel ORA_DISK_1RMAN-
00571: =====================================================
======RMAN-00569: =============== ERROR MESSAGE STACK
FOLLOWS ===============RMAN-
00571: =====================================================
======RMAN-03002: failure of recover command at 06/02/2016
05:55:09RMAN-06094: datafile 6 must be restoredIf data files have been added to
the Primary database during the archive log gap time, theywere not included in
the incremental backup sets. We need to register newly created filesto the Standby
database. We can find newly created files using
CURRENT_SCN of the Standby
.
# Execute the following query at Primary DB - (Last SCN of the Standby
database)SYS> select file#, name from v$datafile where creation_change# >
3473651;FILE# NAME---------- --------------------------------------------
6 /u01/app/oracle/oradata/crms/users03.dbf

Newly created files should be restored at Standby before recovery operation.

RMAN> run{restore datafile 6;}
Starting restore at 02-JUN-16using channel ORA_DISK_1channel ORA_DISK_1:
starting datafile backup set restorechannel ORA_DISK_1: specifying datafile(s) to
restore from backup setchannel ORA_DISK_1: restoring datafile 00006 to
/u01/app/oracle/oradata/stbycrms/users03.dbf
channel ORA_DISK_1: reading from backup piece
/u03/bkp/stby_03r73ftc_1_1channel ORA_DISK_1:
piece handle=/u03/bkp/stby_03r73ftc_1_1 tag=FOR_STBYchannel
ORA_DISK_1: restored backup piece 1channel ORA_DISK_1: restore complete,
elapsed time: 00:00:08Finished restore at 02-JUN-16
# Recover the Standby database using Incremental backup
S
etsRMAN> recover database noredo;
Starting recover at 02-JUN-16using channel ORA_DISK_1channel
ORA_DISK_1: starting incremental datafile backup set restorechannel
ORA_DISK_1: specifying datafile(s) to restore from backup setdestination for
restore of datafile
00001:/u01/app/oracle/oradata/stbycrms/system01.dbfdestination for restore of
datafile 00002:/u01/app/oracle/oradata/stbycrms/sysaux01.dbfdestination for
restore of datafile
00003:/u01/app/oracle/oradata/stbycrms/undotbs01.dbfdestination for restore of
datafile 00004:/u01/app/oracle/oradata/stbycrms/users01.dbfdestination for restore
of datafile 00005:/u01/app/oracle/oradata/stbycrms/example01.dbfdestination for
restore of datafile 00007:/u01/app/oracle/oradata/stbycrms/users02.dbfdestination
for restore of datafile 00008:/u01/app/oracle/oradata/stbycrms/mytbs01.dbfchannel
ORA_DISK_1: reading from backup piece
/u03/bkp/stby_03r73ftc_1_1
channel ORA_DISK_1: piece handle
=/u03/bkp/stby_03r73ftc_1_1
tag=FOR_STBYchannel ORA_DISK_1: restored backup piece 1channel
ORA_DISK_1: restore complete, elapsed time: 00:42:18Finished recover at 02-
JUN-16
All changed blocks has been captured in the incremental backup and also updated
at thestandby database, thus brings the Standby database up to date with the
primary database.
# Start MRP at Standby databaseSYS> alter database recover managed
standby database disconnect;
Database altered.
# Check CURRENT_SCN of the Standby Database
&
Primary databaseSYS> select current_scn from v$database;...
Check the SCNs
in Primary and Standby it should be close to each other.
ARCHIVE LOG SEQUENCE DETAILS AT PRIMARY
&
STANDBY DATABASE
# Maximum generated LOG SEQUENCE# at PrimarySYS> select thread#,
max(sequence#) from v$archived_log group bythread#;THREAD#
MAX(SEQUENCE#)
---------- --------------1 773
# Maximum archive log SEQUENCE# applied at StandbySYS> select
thread#, max(sequence#) from v$archived_log where applied='YES' group by
thread#;THREAD# MAX(SEQUENCE#)
---------- --------------1 773
SYS> select process, status, thread#, sequence#, block#, blocks from
v$managed_standby;
...Wow! Successfully Standby database
S
ynced with Primary database.Check alert.log and status of processes if
any problems;
REFERENCE DOCS :
https://docs.oracle.com/cd/E11882_01/server.112/e41134/rman.htm#SBYDB0075
9 http://docs.oracle.com/cd/B19306_01/backup.102/b14191/rcmdupdb.htm#sthref9
55 https://web.stanford.edu/dept/itss/docs/oracle/10gR2/backup.102/b14191/rcmdu
pdb008.htm
ELOW ARE THE STEPS I FOLLOWED FOR A SUCCESSFUL
RECOVERY
# Check the archive log gap SEQUENCE#SQL> select * from
v$archive_gap;# Find last SCN of the Standby databaseSQL> select
current_scn from v$database;# Cancel the recoverySQL> alter database
recover managed standby database cancel;# Shutdown the StandbySQL>
shutdown immediate;# Backup the Source (Primary) using from SCNRMAN>
backup incremental from SCN XXXXX database format
'/bkp_location/stby_U%'# Backup current control file of the Source (Primary
database)RMAN> backup current controlfile for standby format
'/bkp_location/stby_ctrl.ctl';# SCP backup
S
ets to the target(Standby) Server from Primary$

scp

/bkp_location/* oracle@standby:/standby_location/# Startup Standby

database at NOMOUNT modeRMAN> startup nomount;# Restore control
files from the backupRMAN> restore standby controlfile from '/standby
_location';# Shutdown the Standby databaseRMAN> shutdown immediate;#
Startup the Standby database at MOUNTRMAN> startup mount;# Register
backup sets by a process called catalogingRMAN> catalog startwith '/standby
_location';# Perform RecoverRMAN> recover database noredo;# Restart
MRP at standbySQL> alter database recover managed standby database
disconnect from session;# Check SCN of the Primary and Standby
databaseSQL> select current_scn from v$database;
These are
S
teps I have done to roll the Standby database forward in time. Thats
it!