RMAN Incremental Backups to Refresh Standby Database 

Description to standby:

A standby database is a transactionally consistent replica of the primary database, designed to ensure continuity and data integrity in the event of disasters or data corruption. It allows the primary Oracle database to remain operational even during planned or unplanned outages. If the primary database becomes unavailable, Data Guard can seamlessly promote the standby database to the primary role, minimizing downtime. Additionally, the performance of the primary database can be optimized by redirecting resource-intensive tasks such as backups and reporting to the standby system. Therefore, keeping the standby database synchronized with the primary database is always advantageous.

A standby database might lag behind the primary for various reasons like:

• Unavailability of or insufficient network bandwidth between primary and standby database
• Unavailability of Standby database
• Corruption / Accidental deletion of Archive Redo Data on primary

CHECK THE SEQUENCE IN BOTH NODES:

PRIMARY:

SQL> select thread#, max(sequence#) “Last Primary Seq Generated” from v$archived_log val, v$database vdb where val.resetlogs_change# = vdb.resetlogs_change# group by thread# order by 1;

THREAD#        Last Primary Seq Generated

———-                ————————–

1                                  556

STANDBY:

SQL> select thread#, max(sequence#) “Last Primary Seq Generated” from v$archived_log val, v$database vdb where val.resetlogs_change# = vdb.resetlogs_change# group by thread# order by 1;

THREAD#               Last Standby Seq Generated

———-                       ————————–

1                                    184

STANDBY:

STOP THE MRP PROCESS:

SQL> alter database recover managed standby database finish;

Database altered.

CHECK THE SCN IN STANDBY:

SQL> select current_scn from v$database;

CURRENT_SCN

——————-

58830024

SHUTDOWN THE STANDBY DATABASE:

SQL> shut immediate

ORA-01109: database not open

Database dismounted.

ORACLE instance shut down.

PRIMARY:

TAKE THE RMAN INCREMENTAL BACKUP FROM THE SCN IS NOTED IN STANDBY DATABASE:

SQL> !rman target /

Recovery Manager: Release 19.0.0.0.0 – Production on WED Dec 08 14:13:07 2024

Version 19.3.0.0.0

Copyright (c) 1982, 2019, Oracle and/or its affiliates. All rights reserved.

connected to target database: SOURCE (DBID=1539378116)

RMAN> run {

allocate channel c1 type disk format ‘/u01/backup/archive%U.bkp’;

backup incremental from scn 58830024 database;

}

released channel: ORA_DISK_1

allocated channel: c1

channel c1: SID=138 device type=DISK

Starting backup at 08-DEC-24

channel c1: starting full datafile backup set

channel c1: specifying datafile(s) in backup set

input datafile file number=00001 name=/u01/app/oracle/oradata/ORCL/system01.dbf

input datafile file number=00003 name=/u01/app/oracle/oradata/ORCL/sysaux01.dbf

input datafile file number=00004 name=/u01/app/oracle/oradata/ORCL/undotbs01.dbf

input datafile file number=00007 name=/u01/app/oracle/oradata/ORCL/users01.dbf

channel c1: starting piece 1 at 08-DEC-24

channel c1: finished piece 1 at 08-DEC-24

piece handle=/u01/backup/archive2pu4o8oo_1_1.bkp tag=TAG20190622T141800 comment=NONE

channel c1: backup set complete, elapsed time: 00:00:01

Finished backup at 08-DEC-24

released channel: c1

RMAN> exit

COPY THE BACKUP FILE TO TARGET SERVER:

[oracle@localhost oracle]$ cd /u01/backup/

[oracle@localhost backup]$ ls -lrth

total 100M

-rw-r—– 1 oracle oinstall 50M Dec 08 14:18 archive5jdnijdf_1_1.bkp

-rw-r—– 1 oracle oinstall 50M Dec 08 14:18 archive5jdnijdf_1_1.bkp

[oracle@ram backup]$ scp -r archive5* oracle@192.168.1.31:/u01/backup

Prepare Standby ControlFile and New Datafiles:

1. a)Create a standby control file from primary, and then copy onto standby database server. Replace the standby control file by using this newly created one.

— From primary

SQL>ALTER DATABASE CREATE STANDBY CONTROLFILE AS ‘/u01/backup/SOURCEDBSTY.ctl’;

— From Standby

RMAN> SHUTDOWN IMMEDIATE;

RMAN> STARTUP NOMOUNT;

RMAN> RESTORE STANDBY CONTROLFILE FROM ‘/u01/backup/SOURCEDBSTY.ctl’;

1. b)For new datafiles which are in Primary but not in standby database, copy them from primary to standby database server. Then catalog current all standby database datafiles, since the control file has been replaced by primary one.

RMAN> CATALOG START WITH ‘+DATA01/SORUCE_DG/datafile/’;

RMAN> catalog start with ‘/u01/backup/’;

1. c)Switch database to copy from RMAN.

RMAN> SWITCH DATABASE TO COPY;

RECOVER THE DATABASE:

SQL> !rman target /

Recovery Manager: Release 19.0.0.0.0 – Production on WED Dec 08 14:13:07 2024

Version 19.3.0.0.0

Copyright (c) 1982, 2019, Oracle and/or its affiliates. All rights reserved.

connected to target database: SOURCE (DBID=1539378116, not open)

RMAN> recover database;

Starting recover at 08-DEC-24

using channel ORA_DISK_1

channel ORA_DISK_1: starting incremental datafile backup set restore

channel ORA_DISK_1: specifying datafile(s) to restore from backup set

destination for restore of datafile 00001: /u01/app/oracle/oradata/ORCL/system01.dbf

destination for restore of datafile 00003: /u01/app/oracle/oradata/ORCL/sysaux01.dbf

destination for restore of datafile 00004: /u01/app/oracle/oradata/ORCL/undotbs01.dbf

destination for restore of datafile 00007: /u01/app/oracle/oradata/ORCL/users01.dbf

channel ORA_DISK_1: reading from backup piece /u01/backup/archive2pu4o8oo_1_1.bkp

channel ORA_DISK_1: piece handle=/u01/backup/archive2pu4o8oo_1_1.bkp tag=TAG20190622T141800

channel ORA_DISK_1: restored backup piece 1

channel ORA_DISK_1: restore complete, elapsed time: 00:00:07

starting media recovery

media recovery complete, elapsed time: 00:00:00

Finished recover at 08-DEC-24

RMAN> exit

Recovery Manager complete.

START THE MRP PROCESS:

SQL> alter database recover managed standby database using current logfile disconnect from session;

Database altered.

CHECK THE SEQUENCE IN BOTH NODES:

PRIMARY:

LOGS GENERATED IN STANDBY:

SQL> select thread#, max(sequence#) “Last Primary Seq Generated” from v$archived_log val, v$database vdb where val.resetlogs_change# = vdb.resetlogs_change# group by thread# order by 1;

THREAD#        Last Primary Seq Generated

———-                ————————–

1                                     562

STANDBY:

LOGS RECEIVED IN STANDBY:

SQL> select thread#, max(sequence#) “Last Primary Seq Generated”  from v$archived_log val, v$database vdb where val.resetlogs_change# = vdb.resetlogs_change# group by thread# order by 1;

THREAD#             Last Standby Seq Generated

———-                       ————————–

1                                        562

LOG APPLIED IN STANDBY:

SQL> select thread#, max(sequence#) “Last Standby Seq Applied”  from v$archived_log val, v$database vdb where val.resetlogs_change# = vdb.resetlogs_change# and val.applied in (‘YES’,’IN-MEMORY’)  group by thread# order by 1;

THREAD#              Last Standby Seq Applied

———-                       ————————

1                                       562

Conclusion:

By leveraging RMAN incremental backups, it is possible to efficiently synchronize a standby database with the primary database, even in scenarios where there is a lag or data inconsistency. This method ensures minimal downtime, enhances data integrity, and maintains business continuity by enabling the seamless recovery and synchronization of the standby database. Regular monitoring and proactive maintenance of the primary and standby systems ensure the robustness and reliability of the Data Guard setup.