Go Premium for a chance to win a PS4. Enter to Win

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 8239
  • Last Modified:

Restore RMAN backup to another server/instance

I've got an RMAN backup that was taken on server A.  I need to restore the backup to an instance on server B, keeping the database name that's already on B.  The two servers are in different domains.

This is Oracle 10g.

Is there a good writeup or advise on how to do this?  It seems that the articles that I've found don't agree on the steps and/or complexity.


Thanks,
Kent
0
Kent Olsen
Asked:
Kent Olsen
  • 6
  • 5
2 Solutions
 
Steve WalesSenior Database AdministratorCommented:
It's not overly difficult.

You don't say what OS you're on, because there's extra steps involved in windows (you need to create the service using ORADIM before you start) that are not required in Unix.

Start by copying the backup files you need over to the new server.
Get a modified init.ora file on the server somewhere that includes the directives DB_FILE_NAME_CONVERT and LOG_FILE_NAME_CONVERT to rename your data and log files during the copy.

DB: http://docs.oracle.com/cd/B19306_01/server.102/b14237/initparams048.htm
LOG: http://docs.oracle.com/cd/B19306_01/server.102/b14237/initparams112.htm

If directory locations on the new server are exactly the same, and the file names are exactly the same, I guess you don't need those.

Start up your new database NOMOUNT, pointing to the pfile you've created (make sure that changes such as database name, domain name, memory settings and the two parameters above are set in there).

Invoke RMAN:  rman auxiliary /

Then run this script:

run
{
allocate auxiliary channel aux1 device type disk;
duplicate database to new_db_name until time "to_date('2014-03-11 08:00:00','YYYY-MM-DD HH24:MI:SS')" backup location '/path/to/your/backups';
}

Open in new window


It will go looking for the autobackup of the controlfile from your source backup and do the duplicate.  If your backup is an offline backup, you don't need the until time part of the duplicate command.  If you can connect to both databases (your source as target and your new one as auxiliary, and server B can read from server A backup destination) then you don't need backup location either.  It can read that from the source controlfile.

Make sure that when you copy the backup files over, you have everything - the full/incremental level 0, and differentials, logs and controlfile backups.

I have a couple of windows environments where I do it this way and a couple of unix environments where the backup location from prod is mounted on the test box when we need to do a restore.

When done, stop and restart the database with an init.ora that doesn't have the CONVERT parameters.  Create the spfile from your pfile and if it's a test database that you don't want in archivelog mode, turn that off.
0
 
Kent OlsenData Warehouse Architect / DBAAuthor Commented:
Cool.  I'll give that a shot.  Thanks.

And it is Windows.  :(


Kent
0
 
Steve WalesSenior Database AdministratorCommented:
Creating the database service on windows is pretty easy:

oradim -new -sid newdb -startmode auto -pfile 'c:\oracle\product\10.2.0\db_1\dbs\initnewdb.ora'

Then you can continue from there as described above.

Make sure you execute the command using a privileged account etc :)  Not everyone can create a service.

You are probably better off copying the backups from A to B then, if you're on Windows.

Oracle services accessing remote disks is a pain.  I had no end of troubles when I had a test machine set up using a domain account as the service owner that could access my prod backup location.  Caused me way more trouble than it was worth so I went back to the default ownership of the service - but then the backups for this particular machine aren't incredibly large and I can copy everything I need over in 30-60 minutes usually.
0
Get your Conversational Ransomware Defense e‑book

This e-book gives you an insight into the ransomware threat and reviews the fundamentals of top-notch ransomware preparedness and recovery. To help you protect yourself and your organization. The initial infection may be inevitable, so the best protection is to be fully prepared.

 
Pepe2323Commented:
Hi

what i have done to do something like this is:

- Move the rman backup to the Server B
- Copy pfile to the server b, put the pfile $ORACLE_HOME/dbs
- set pfile as cluster = false
- FOR RAMN:

rman nocatalog

connect target /

shutdown abort;
startup nomount;

Restore control files

RMAN> restore controlfile from 'path/backup_file'
alter database mount;
CROSSCHECK ARCHIVELOG ALL;
CROSSCHECK BACKUP;
CATALOG START WITH '/backup/path/' NOPROMPT;
restore database;
recover database;

When recover finish:
shut immediate

sqlplus  / as sysdba
startup

Pretty Much those are steps i follow

Regard.s
0
 
Steve WalesSenior Database AdministratorCommented:
Both methods are valid.  One is a pure restore which will restore everything in the same format as the original - pathing, names, DBID ... everything.

The other is a copy that lets you move things around as you do the restore and change the name etc.

Depends on the exact requirements of the OP.
0
 
Kent OlsenData Warehouse Architect / DBAAuthor Commented:
I'm looking for an easily repeatable process.  I've got several dozen instances that I'm going to rehost.  They all have the same file structure so all I really need to do is lay the instance over an existing instance and make sure that the new instance name is correct.

I tried Pepe's solution.  The (original) spfile isn't being picked up.  The "alter database mount" is failing with "database name {backup name} is not {instance name}".
0
 
Steve WalesSenior Database AdministratorCommented:
If all you are doing is moving the databases from one machine to another and everything else is the same (same OS version, same DB version, same disk layout, same everything) you could shut the DB down, move everything over to the new server and start it up.

I have done that before I seem to recall.

Depends if you can stand the outage to get it done.
0
 
Kent OlsenData Warehouse Architect / DBAAuthor Commented:
An outage isn't a problem.

I was actually wondering if it would be easier to drop the instance and recreate it.
0
 
Steve WalesSenior Database AdministratorCommented:
Just wondering how that would help here ?  You still need to get the data, users, etc over to the new server.

Doing a copy via RMAN, or copying the files from an offline backup will move everything that makes up the internals with it.

If you have to create a new DB and then copy the data, you have issues with recreating all the internals - users, roles, permissions, code, etc.
0
 
Kent OlsenData Warehouse Architect / DBAAuthor Commented:
I'm not sure that it would help.  And thinking about it some more, it probably doesn't.

The way our environment is set up, we've never had to do an instance restore from the RMAN backups.  Authentication stays with the server so we've used imp/exp or impdp/expdp to move data between servers when we had to.

Our business model is changing and I'm drawing a blank on the RMAN restore.  I haven't seen it in 8 years.
0
 
Steve WalesSenior Database AdministratorCommented:
Wanted to make sure you have what you needed from the above, Kdo.

There have been 2 ways presented to you - a duplicate or a restore - both have different ways of handling things.

The duplicate will assign a new DBID to the copied database, a restore will end up with the same DBID.

I am more than willing to go through either in detail if needed - want to make sure you have not been left hanging - your last reply doesn't indicate if you need further assistance or not :)
0
 
Kent OlsenData Warehouse Architect / DBAAuthor Commented:
Hi guys,

I wound up choosing door number 3 -- Create a new instance and restore the containers to the instance directories.

Thanks for the help!


Kent
0

Featured Post

Veeam Task Manager for Hyper-V

Task Manager for Hyper-V provides critical information that allows you to monitor Hyper-V performance by displaying real-time views of CPU and memory at the individual VM-level, so you can quickly identify which VMs are using host resources.

  • 6
  • 5
Tackle projects and never again get stuck behind a technical roadblock.
Join Now