When you think about architecting your backup strategy, as part of the process, you must also consider how you are going to restore and recover.

Your backups are only as good as the last time you tested a restore and recovery. A backup strategy can be rendered worthless without a good restore-and-recovery strategy.

The last thing you want to happen is to have a media failure, go to restore your database, and then find out you are missing critical pieces, you do not have enough space to restore, something is corrupt, and so on.

One of the best ways to test an RMAN backup is to restore and recover it to a different database server. This will exercise all your backup, restore, and recovery DBA skills.

If you can restore and recover an RMAN backup on a different server, it will give you confidence when a real disaster hits. You can think of all the prior material in this book as the building blocks of how backup and recovery works.

Note rMaN does have a DUPLICATE DATABASE command, which works well for copying a database from one server to another. If you are going to be performing this type of task often, I recommend that you use rMaN’s duplicate database functionality. however, you may still have to copy a backup of a database manually from one server to another, especially when the security is such that you cannot directly connect a production server to a development environment.you can use rMaN to duplicate a database based on backups you copy from the target to the auxiliary server. see Mos note 874352.1 for details on targetless duplication.

In this example, the originating server and destination server have different mount points. Listed next are the high-level steps required to take an RMAN backup and use it to re-create a database on a separate server:

1. Create an RMAN backup on the originating database.

2. Copy the RMAN backup to the destination server. All steps that follow are performed on the destination database server.

3. Ensure that Oracle is installed.

4. Source the required OS variables.

5. Create an init.ora file for the database to be restored.

6. Create any required directories for data files, control files, and dump/trace files.

7. Start up the database in nomount mode.

8. Restore the control file from the RMAN backup.

9. Start up the database in mount mode.

10. Make the control file aware of the location of the RMAN backups.

11. Rename and restore the data files to reflect new directory locations.

12. Recover the database.

13. Set the new location for the online redo logs.

14. Open the database.

15. Add the temp file.

16. Rename the database (optional).

In this chapter and previous chapters, we discussed how to do all of these steps. The difference here is that steps 3–16 are performed on the new destination server, and this provides you the checklist to restore on a different server.

If the originating server and destination server have different mount point names, you will need to make sure to rename the files.

RMAN can be used for any type of restore-and-recovery scenario. If found in a situation for needing to restore, take a breath, remember your practice, and think through your options. It might be instinctive to go to restoring the entire database, but a FLASHBACK QUERY might be all that is needed. Be sure to validate and preview the restore as this will make sure you have the files you need and set you up for a successful restore. Testing and practicing ensures you have good backup files and strategy and allows you to be able to think through the best way to restore and recover your database.