Cloning a database

[Brendan McDonald]

Hi, i'm using RMAN to backup my production database and would now liek to clone this database to my DEV environment.

Now, I unerstand that RMAN can do this by connecting to the DEV database but I have firewalls in the way and a total seperation of Prod and DEV environments (it's just the way we do things round here).

I've tried renaming (after copying to tape and back off tape) the RMAN backups to their original data file names and running a create database and recreating the control files and then recover database from archive files but however far I go with this method (approx 12 hours after the backup was taken) i get datafiel 1 (system) still needs recovery.

Has anyone ever doen anything like this before ?? Is there a way of registering my PROD RMAN backups with my DEV RMAN so I can import the backups and then do a complete recovery ???

Any help on this would be much appreciated.

Thanks

[Steven E. Protter]

Shalom,

Best method to clone.

Get a cold backup and copy it to the new server and follow Oracle cloning procedures.

You will have to get rman to make this database a physical file that you can move, copy it and use RMAN to import it on the second system. This is much harder than the ideal methodology.

SEP

[Yogeeraj_1]

hi,

there must be a problem with the restore of your control files. Can you verify that it has been restored correctly prior to the recovery?

kind regards
yogeeraj

[Nanjappa]

Hi,
10 steps for cloning a database.

The following steps must be on Source -Production instance/Server
Step 1. Shutdown database in normal mode and start it up in restricted mode.
Step 2. Take the backup of control file
Step 3. Shutdown database again in normal mode.
Step 4. Copy /FTP init parameter file ,control file script and all the database file on the destination server/location, once all the files are successfully copied, you may startup the database normally.

The following step must be on destination â Clone instance/server
Step 5. Edit init parameter file and control file script.
Step 6. New Environment setup .
Step 7. Connect with svrmgrl and recreate control file
Step 8. Open the database in resetlogs.
Step 9. Shutdown the database in normal mode
Step 10. Take the cold backup and start the database in archive/non archive mode.

If your database is 10g then you have an hyper link in Enterprise Manager for clonning database.

[Eric Antunes]

Hi Brendan,

Avoid all this cloning work and just use the same SID on both servers (environments).

That's how I have things here and all I just need to do to refresh the DEV environment is to copy the PROD files to the DEV server.

Best Regards,

Eric Antunes

[Yogeeraj_1]

hi again,

concerning cloning, i would also choose Eric's method of managing the production and test environment.

if need be, the global name can also be changed using:
alter database rename global_name to dev.domain.mu;

you should keep things simple.

kind regards
yogeeraj

[Brendan McDonald]

Hi guys, thanks for your input.

My problem is my PROD server is a 24 / 7 server and can never be shut down (unscheduled at least), that's why i'm doing online backups using RMAN. My environments are exactly the same Prod & DEV (same oracle_home, sid & even file structures).

As i said, i've tried renaming (after copying to tape and back off tape) the RMAN backups to their original data file names and running a create database and recreating the control files and then recover database from archive files but however far I go with this method (approx 12 hours after the backup was taken) I get datafile 1 (system01.dbf) still needs recovery. As you know you can't copy your RMAN files onto the DEV server and start up the database without some sort of recovery being needed.

I found mention of being able to register other backups with RMAN (so it puts a record into the control file) and then once registered you can then do your database recovery the standard way. But I can't find a detailed way of doing this.

Maybe i'm barking up the wrong tree but I need to be able to clone from PROD to DEV. I thought this would be a relatively simple matter with RMAN.

All help with this conundrum would be much appreciated.

[spex]

Hi,

The last logfile you need to apply for recovery will be an online redo logfile.

After you back up the datafiles and archivelogs, force a logfile switch. Then make sure to also back up this last logfile (it will be smaller in size than the others, ending with sequence # N-1).

PCS

[Yogeeraj_1 · Accepted solution]

hi,

your FULL RMAN recovery steps should be as follows:

1. Database startup (nomount)
sqlplus "/ as sysdba" <startup nomount;
exit;
EOF

2. RMAN recover the control files

#!/usr/bin/ksh
rman target system/manager rcvcat rman/rman@catalogdb <run{
allocate channel c1 type disk;
restore controlfile;
}
exit;
EOF

3. Mount the database
sqlplus "/ as sysdba" <alter database mount;
exit;
EOF

4. RMAN full database recover

#!/usr/bin/ksh
rman target system/manager rcvcat rman/rman@catalogdb log=rman_reco_full.log
<run {
allocate channel c1 type disk;
allocate channel c2 type disk;
set newname for datafile 1 to '/d01/oracle/oradata/mydb/system01.dbf';
...
restore database;
switch datafile all;
}
exit;
EOF

5. Recover your archived logs

rman target system/manager rcvcat rman/rman@catalogdb log=rman_reco_al.log <run {
allocate channel c1 type disk;
allocate channel c2 type disk;
allocate channel c3 type disk;
allocate channel c4 type disk;
set archivelog destination to "/d01/app/oracle/admin/mydb/arch/";
restore archivelog from logseq= until logseq=;
}
exit;
EOF

6. Recover the database itself!
sqlplus "/ as sysdba" <recover automatic database using backup controlfile;
exit;
EOF

7. Open the database for use
sqlplus "/ as sysdba" <alter database open resetlogs;
exit;
EOF


do this helps?

kind regards
yogeeraj

[gthai]

Follow spex advice.
You're too far along the way to go back and take another backup. BTW, if you're using RCAT do pay attention to DBID. You'll find that it is the same as your production so be careful not restore/recover the wrong database.

(set NLS_DATE_FORMAT if recover unitl time)
SQL>recover database using backup controlfile until cancel;
apply all the archivelogs up to the last online redolog.
type cancel
SQL>alter databse open resetlogs;

[Brendan McDonald]

Thanks for the RMAN recovery details but if you look back, i've got PROD RMAN backups and I need to import these into the DEV RMAN backup catalog. I need to do this before I can recover my database.

Any help to import different backup details into the recovery catlog would be much appreciated.

thanks

[William Lai]

Hi,

Have you try the following:

on PROD env
a) copy the backupset to DEV env
b) alter database backup controlfile to '/tmp/PRODcntl.bin'
c) copy PRODcntl.bin to DEV env

on DEV env
a) use PRODcntl.bin as the DEV instance control file
b) startup DEV insntace mounted
f) rman connect to DEV instance
g) list bakcupset (if you can see the backupset created in PROD, then proceed with an incomplete recovery)

NOTE: you will not be able to perform COMPLETE recovery WITHOUT shutting down PROD instance. As the most current redo entries are still in the CURRENT ONLINE REDO.

Regards,
William

[Yogeeraj_1]

hi,

Quite odd that you are keeping the RMAN catalog in the same database that is being backed up!!

If you go through the documentation, you will see that they recommend you that the catalog should be another database.

Anyway, to do what you want to do, just do an export/import

e.g.
exp rman/rman@catalogdb file=rman_db log=rman_dbexp.log

then
imp system/manager@othercatalogdb file=rman_db log=rman_dbimp.log fromuser=rman touser=rman


hope this helps!

kind regards
yogeeraj

[TwoProc]

In your recovery step, did you...

"recover database using backup controlfile until cancel;" ???

If not, when the thing keeps asking for another file, you can try "recover cancel";

And, it should let you open the database.

If it doesn't, you'll probably have to do the whole backup and recover anyways. I don't know what causes it, but I've seen what you're talking about(can't seem to recover enough), and it happens rarely. I've seen it happen to where back at the production box I've tried spitting out new redos to give to the cloned database. Still didn't work.

[Brendan McDonald]

Ok, i'll be testing some of these solutions over the coming few days. I'll wait until I have it done before assigning points.

Thanks.

[Brendan McDonald]

Hi Yogeeraj, I tried you're idea yesterday but what when trying to recover the controlfile -

#!/usr/bin/ksh
rman target system/manager rcvcat rman/rman@catalogdb <run{
allocate channel c1 type disk;
restore controlfile;
}
exit;
EOF

It looks for the controlfile in the flash_recovery area. I've tried setting the disk location to my backup area but won't allow me unless the database is mounted.

I'm running my catalog in the control files. Could this be the reason why it's only looking int he flash recovery area. If I had a recovery catalog in a smaller instance would this method work ???

I'm going to try using the clone database option within EM to the same server and see if this works.

Thanks.

[Brendan McDonald]

Ok, what i'm doing as I don't havae a catalog db to be able to use Yogi's solution is to clone the database (from the EM console).

I clone the db to the same server, shutdown the database once it's done and then include it as part of my tape backup. On my DEV server, i simply copy the files into place and recreate my control files and it's all ok.

The best bet about this solution is that i can schedule the clone to run in the early hours of the morning (as it does slow th server down for a period) when I need it to run (I definately won't be running this every day).

Thanks