Using Recovery Manager (RMAN) for Instantiation

The Recovery Manager (RMAN) method of instantiating a target Oracle database is suitable for providing a physical, block-based instantiation which offers faster performance for large-scale data transfers. The RMAN process creates the target database by restoring a backup of the source database.

For large databases that are in the terabyte range, logical instantiation methods can be time-consuming and inefficient. In such cases, Oracle RMAN is a preferred solution for creating a physical clone of the source database.

The following steps outline the tasks performed during a RMAN-based instantiation for target Oracle database:

  1. Use a backup of the source database.

  2. Restore the backup to a new auxiliary (cloned) database.

  3. Perform media recovery on the cloned database to bring it to a consistent state.

  4. Configure and adjust the cloned database to meet the specific requirements of the target environment.

When using RMAN cloning for Oracle GoldenGate, it’s important to manage the timing of replication to avoid data loss and ensure seamless integration. The key is to identify the point in time (or SCN) when the target database was consistent, so that both the source and target databases stay in sync.

To do this, start the Oracle GoldenGate Extract process on the source database before the backup is taken. If you find a transaction that has an older timestamp than when you registered Extract, you must wait until that transaction has completed. This is important as Extract only processes complete transactions. After the target system is set up through cloning, direct the replication changes to the target system using the DISTPATH and add the Replicat process. When you start the Replicat, make sure to start exactly at the SCN where the target database was recovered.

The following example explains the use of SCN when cloing a database using the backup from the source database.

On the source database, the backup, which is scheduled at 10 PM, is running. The backup includes database files and archive logs, which are backed up more frequently. The backup finishes at 10:30 PM with an SCN of 1420004711. This backup is then used to clone (restore and recover) the new target database. File copying, restore, and recovery take several hours, after which, the new target database is ready. At this point, both the source and target databases are consistent, as shown in the following diagram.
Source Database backup is cloned using the SCN value.

As time passes, new changes continue to occur on the source database, and its SCN increases. To keep the target database in sync, Oracle GoldenGate’s Extract process captures changes starting from a point before the backup was taken.

Even though the Replicat process is not started immediately, when it is, it will ignore any changes that occurred before the STARTCSN (the SCN to which the target database was recovered). After that point, Replicat begins applying the backlog of changes. After Replicat is in sync, replication transitions into the normal, real-time phase.

Refer to the Duplicating Databases topic in the Oracle Database Backup and Recovery User’s Guide, which provides detailed steps to set up a cloneed target database using RMAN.