RMAN: restore database on another node including rename

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:
As root:
>> 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.

As Oracle:
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

Cloning / duplicating with RMAN, the basics

Cloning / duplicating with RMAN, the basics

It is considered  a skill every DBA should have, cloning a database with RMAN.  But still meeting DBA’s which never used this… Decided to write down some basic RMAN-stuff , just as a notepad, and maybe it’s helpfull for others..

My own basic checklist through an example:


Cloning / duplicating with RMAN, the basics

Backup database shell-script with RMAN

A proper backup is the base for a well and relaxed administration of yout databases.What follows is a backup-script which I use for several customers. It’s backing up all in the same directory and I tested the restore frequently.

There’s however one drawback: I copied the script through word- or notepad apparently, so take care of the (double) quotes used in the script. You may have to re-type them.