In my urge to write down some basic RMAN-checklists I could use in the future, consider the following:
You’ve got no DataGuard at your disposal. Single node, relying on your RMAN-backup on disk, which is fortunately copied to tape. Now your complete node is burning down. What’s is left is your RMAN-backup (made by this script).
In a bad scenario you’ll have to restore this to another node.
No rocket science, but at that very moment you’re not very relaxed, and will be happy that it’s documented in the past by or for you how to do it. Also to be used to make a copy of the production-database, however I find the technique of ‘duplicating with RMAN‘ easier and more adequate for this purpose. Here are the basics of a restore on another node and give the database another name. Yes, it can be scripted and make it faster at certain points , but that’s not the point in this story….
Example: restore the database DEVDB (node LARRY) on the node ELLISON and give it the name DEVDBNEW.
The daily backups on LARRY are on /local/data/oracle/rman/DEVDB
On ELLISON, create the same backup-directory:
>> mkdir –p /local/data/oracle/rman/DEVDB
>> chown –R oracle:oinstall /local
As an alternative: if there is already a /backup/data/oracle or something like that, use a symbolic link:
>> ln –s /backup local
The intention here is to copy the bunch from LARRY to ELLISON, but if it’s possible, you can always mount the directory ‘/local/data/oracle/rman/DEVDB’ on ELLISON to the same directory on LARRY, so you don’t have to copy. Saves a lot of time, only be aware of the ‘..cfc..’-file. If the origin database is in ‘autobackup’ mode, this file will be overwritten by the origin database when there are changes. Also the new database is using this file, while restoring and may also be in autobackup-mode. So make a copy of the original file (which has a date which is the end of the backup you are using).
Find out where the files should be placed:
select name from v$tempfile
select member from v$logfile
select name from v$datafile
select name from v$controlfile;
or: use ‘report schema’ in RMAN.
Edit /etc/oratab on ELLISON, with the origin name, temporarily:
Run .oraenv (DEVDB), for the right environment.
Create directories for the database files (these ones already with the new db name):
>>mkdir –p /data10/oradata/DEVDBNEW/arch
Create new backup directories:
>> mkdir –p /backup/ELLISON/DEVDBNEW/export
>> mkdir –p /backup/ELLISON/DEVDBNEW/rman
Create directories for the admin files (with the new db name):
>> mkdir –p /software/oracle/product/10202/admin/DEVDBNEW/adump
>> mkdir –p /software/oracle/product/10202/admin/DEVDBNEW/bdump
>> mkdir –p /software/oracle/product/10202/admin/DEVDBNEW/cdump
>> mkdir –p /software/oracle/product/10202/admin/DEVDBNEW/udump
>> mkdir –p /software/oracle/product/10202/admin/DEVDBNEW/scripts
>> mkdir –p /software/oracle/product/10202/admin/DEVDBNEW/pfile
>> mkdir –p /software/oracle/product/10202/admin/DEVDBNEW/dpdump