Modify the init.ora file so that it matches the destination box in terms of any directory paths. Copy the init.ora file from the source server to the destination server, placing it in the ORACLE_HOME/dbs directory.
Here are the settings for ORACLE_SID and ORACLE_HOME on the destination server: $ export ORACLE_SID=TRG The destination database name will be changed as part of the last step in this list, to DUP. The ORACLE_SID variable is initially set to match what it was on the source database ( TRG in this example). On the destination server establish the OS variables, such as ORACLE_SID, ORACLE_HOME, and PATH. On the destination server, ensure you have the same version of the Oracle binaries installed as you do on the originating database.ĥ. This exampl.nux/UNIX scp command to copy the backup pieces (initiated from the destination server): $ scp /u01/rman/DUPĤ. Copy the RMAN backup to the destination server. For this example the destination server directories created are: $ mkdir -p /u01/rman/DUPģ. On the destination server, create any required directories for data files, control files, and so on. Also notice for this example that the backup pieces on the source server are in the /u01/rman/TRG directory.Ģ. You’ll need to reference the prior backup piece file when you restore the control file on the destination server (step 8). Verify that a backup of the control file exists: RMAN> list backup of controlfile
RMAN> configure controlfile autobackup on Īlso include the archive redo logs as part of the backup, as shown: RMAN> backup database plus archivelog When backing up a database, make sure you have the autobackup control file feature turned on: $ rman target / Create an RMAN backup on the source (target) database. You’ll have to adjust these directory names to reflect the directory structures on your database servers. Also notice that the originating source server and destination server have different directory names. For this example the source database is named TRG, and the destination database is named DUP. All remaining steps are performed on the destination server. Notice in Figure 1 that only step 1 occurs on the source database server. Manually cloning a database using an RMAN backup This scenario is depicted in Figure 1.įigure 1. The next example will do just that it uses an RMAN backup to restore and recover a database on a different server. Moving a database from one server to another using an RMAN backup requires an expert-level understanding of the Oracle architecture and how backup and recovery works.
If you can restore and recover an RMAN backup on a different server, it will give you confidence when a real disaster hits. This will exercise all your backup, restore, and recovery DBA skills.
One of the best ways to test an RMAN backup is to restore and recover it to a different Oracle database 12c server. The last thing you want to happen is to experience a media failure, go to restore your database, and then find out you’re missing a file, you don’t have enough space to restore, something is corrupt, and so on. A backup can be rendered worthless without a good restore and recovery strategy. Your backups are only as good as the last time you tested a restore and recovery. When you think about architecting your backup strategy, as part of the process you must also consider how you’re going to restore and recover Oracle Database 12c.