How to create the standby database using the primary database backup

Creating a Standby Database Without Impacting Primary Performance

In many organizations, we often receive requests to create a standby database for the production environment. One of the common approaches is using Active Duplicate, but this method can affect the performance of the primary database, especially if the database is large.

My Preferred Strategy

To avoid any performance impact on the primary system, I generally create the standby database from an existing backup and then enable log shipping. This method allows us to restore massive amounts of data without touching the production system, and once restoration is complete, we configure log shipping as usual.

---

Step-by-Step Guide

1. Ensure You Have a Valid Backup

Make sure your daily RMAN backup is running (either on tape or disk).

If a full or incremental backup already exists, there’s no need to take another backup.

If not, take a full backup of the primary database.

2. Backup the Standby Control File from Primary

Use the following RMAN command on the primary database:

On Primary server:

RMAN> BACKUP CURRENT CONTROLFILE FOR STANDBY FORMAT '/tmp/standby_DBNAME_1.bck';

3. Transfer Control File to Standby Server

Copy the file /tmp/standby_DBNAME_1.bck from the primary to the standby server.

---

On the Standby Server

4. Restore the Control File

Create a pfile on the standby server (you can refer to the primary database’s pfile).

Start the standby instance in NOMOUNT state.

Run the following RMAN command to restore the control file:

RMAN> RESTORE STANDBY CONTROLFILE FROM '/tmp/standby_DBNAME_1.bck';

---

5. Mount the Standby Database

Once the control file is restored, mount the standby database:

SQL> ALTER DATABASE MOUNT STANDBY DATABASE;

---

6. Restore and Recover the Standby Database

Use the following RMAN script to restore and recover the standby database from backup. This example assumes you're using tape backup (TSM):

RUN {

  ALLOCATE CHANNEL t2 TYPE 'sbt_tape' PARMS 'ENV=(TDPO_OPTFILE=/opt/tivoli/tsm/client/oracle/bin64/tdpo_DBNAME.opt)';

  ALLOCATE CHANNEL t3 TYPE 'sbt_tape' PARMS 'ENV=(TDPO_OPTFILE=/opt/tivoli/tsm/client/oracle/bin64/tdpo_DBNAME.opt)';

  ALLOCATE CHANNEL t4 TYPE 'sbt_tape' PARMS 'ENV=(TDPO_OPTFILE=/opt/tivoli/tsm/client/oracle/bin64/tdpo_DBNAME.opt)';

  ALLOCATE CHANNEL t5 TYPE 'sbt_tape' PARMS 'ENV=(TDPO_OPTFILE=/opt/tivoli/tsm/client/oracle/bin64/tdpo_DBNAME.opt)';

  ALLOCATE CHANNEL t6 TYPE 'sbt_tape' PARMS 'ENV=(TDPO_OPTFILE=/opt/tivoli/tsm/client/oracle/bin64/tdpo_DBNAME.opt)';

  ALLOCATE CHANNEL t7 TYPE 'sbt_tape' PARMS 'ENV=(TDPO_OPTFILE=/opt/tivoli/tsm/client/oracle/bin64/tdpo_DBNAME.opt)';

  

  RESTORE DATABASE;

  RECOVER DATABASE;

}

7. Enable the Log shipping parameters at primary and standby side, I am not putting those things considering that those things should be known and can be setup.. we need to put some parameters at both side.

---

Final Thoughts

This method is especially useful for large databases, where active duplication would otherwise degrade the primary system’s performance. By leveraging existing backups and configuring the standby database properly, we can achieve a seamless setup with minimal impact on production.