RMAN and DB refresh ....

Hi All,

I'm interested in knowing how do you all deal with the following scenario. Also my warning is that do't say that its test who cares :D

Setup: RMAN 8i (test & prod)
Catalog DB 9i
Catalog Schema 9i

Say you have one production and one test databases. Both are being backedup using RMAN into their own catalog schemas in the catalog db. Now you need to do the refresh of test from production. The problem is when you use the RMAN to do the duplicate, it would change the DBID of the test, as a result you'll have to re-register the test database in the the test db's catalog. This leaves the old DBID to coexist in the same catalog. As you may have encountered, you cannot delete the old backupsets from the old dbid catalog, as RMAN would require you to connect to both the target and catalog to delete the backupsets. Other problem is that how do one recover from the old DBID catalog, if for somereason, one would have to roll back to that point before the refresh?

Could someone tell me how do you all deal with these kind of scenarios through RMAN?

Thanx,
Sam

You can unregister your test database. However, this would leave the old incarnation un-restorable.

I would probably:
1. clone my recovery catalog to a test box
2. use my cloned recovery catalog to restore my prod database
3. create a new catalog schema in the prod catalog
4. register my new test database with the prod recovery catalog.

This way, if you need to restore either version of your test, it will be there. If you have to open your cloned test db with resetlogs it wont mess up your production recovery catalog.

Hi Jeff thanx for the thoughts. But it sounds like a painfully delightful solution :) The reason behind this question was, currently we use a home brewed script to do a hot copy and then hatch the database from the hotcopy. This process of cloning/refreshing dbs doesn't change the DBIDS. As a result we have a number of dbs with the same DBIDs. So when I implemented the RMAN, I had to resolute to that of maintaining individual catalogs for each database. Now the RMAN works charmfully with the refresh process. My MAJOR fear is that, what if some curious minded person (i.e. DBA) goes and turns on the AUTO BACKUP OF CONTROLFILE. Bingo, that would be the recipe for disaster on a disaster recovery system. Because this uses the %F tag (i.e the DBID), it would end up looking at the wrong controlfile at the time of recovery. So, thought of pushing towards chaning the DBIDs. Since here we do a v.frequent refreshes, not all the DBAs are going to be happy with the opinion of the process you described Jeff.

Is there a way where we could change the DBID to a specific DBID in a database. If there is one, then it would be wonderful. This way, I can clone the DB using RMAN and then change the DBID to the old one and reset the catalog.

Anythoughts ?

Sam

Quote:

---

Originally posted by sambavan

Is there a way where we could change the DBID to a specific DBID in a database. If there is one, then it would be wonderful. This way, I can clone the DB using RMAN and then change the DBID to the old one and reset the catalog.

---

Not as far as I know.

O.K here we go. After a few grewling hours of toasting my brains, I think we can achieve it through, though this was not what I intend to have but it still helps me to keep things simple, straight forward and feasible.

Only thing in this case is that you want to retain the old catalog registry for doing any kind of recovery here (i.e you do not want to unregister the old db from your catalogs). A simple test case

1. take a backup of your target
2. duplicate it into auxilliary
3. create and register the auxillary catalog
4. take a backup of your auxillary
5. duplicate your earlier target into auxillary
6. re-register the auxillary in your auxillary catalog

Now comming to the scenario of recovery
7. connect to the catalog
8. Get the dbid of from the catalog that you want to recover
in this case the first id
9. connect to rman as follows

Quote:

---

rman
RMAN> set DBID=dbid you want to recover;
RMAN> connect target /;
RMAN> connect catalog catalog_user@catalog_db
RMAN> shutdown immediate;
RMAN> startup nomount;
RMAN> run {
allocate channel ...
set until time 'NLS_DATE_FORMAT';
restore controlfile;
alter database mount;
restore database;
recover database;
sql "alter database open resetlogs";
}

---

10. If the recovery goes successful, you would be using
the old catalog with the old dbid from now on.


Hope this may help others too.

Sam

Quote:

---

Originally posted by sambavan
My MAJOR fear is that, what if some curious minded person (i.e. DBA) goes and turns on the AUTO BACKUP OF CONTROLFILE. Bingo, that would be the recipe for disaster on a disaster recovery system. Because this uses the %F tag (i.e the DBID), it would end up looking at the wrong controlfile at the time of recovery.

---

Change your backup script to include an additional controlfile backup with a different format. Thats a simpler solution :). Even if someone turns autobackup on, no bigdeal. Just restore the correct one later.

See below how my piece name is different from the DBID.

BACKUP format 'dwdev_ctrl_file_%t_%s_%p' tag='DWDEV incr0 curr control file' current controlfile;

RMAN> list backup tag='DWDEV incr0 curr control file';
List of Backup Sets
===================
BS Key Type LV Size Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ ---------------
2760 Full 7M SBT_TAPE 00:00:01 08-JUL-04
BP Key: 3594 Status: AVAILABLE Tag: DWDEV INCR0 CURR CONTROL FILE
Piece Name: dwdev_ctrl_file_531009267_2448_1
Controlfile Included: Ckp SCN: 3375229838 Ckp time: 08-JUL-04

RMAN> list incarnation;
List of Database Incarnations
DB Key Inc Key DB Name DB ID CUR Reset SCN Reset Time
------- ------- -------- ---------------- --- ---------- ----------
1 42 DWDEV 294984608 NO 1 18-FEB-00
1 2 DWDEV 294984608 YES 3165156180 13-MAY-04
6674 6697 DWTEST 2134756332 NO 1 17-FEB-00
6674 6675 DWTEST 2134756332 YES 3165804271 14-MAY-04
9728 9729 DWPROD 3838902646 YES 1 07-FEB-00

Actually, I do have those things in place. Still, rman by default went for the one backedup by auto backup. Its not a big of a deal to aliviate this problem. All you need to do is the put some unique text infront of the %F format. That would fix the problem. The issue is that every time you do some change, to have to be v.careful to make sure the uniqueness is preserved on the server. But in a farm like ours, its really hard to maintian it. So, my solution is just, keep them all turned off. :D Though they are good feature, it has the capability to cause a caos :)

Sam

if your database is 9.2 then you can use NID to modify DBID

http://metalink.oracle.com/metalink/...&p_id=224266.1

Thanx Pando for the suggestion. I'm aware of NID and have used it on 8i DBs too. The problem here is that I want to retain the old DBID for the refreshed database, instead of the DUPLICATE going and creating a new one. THE NID, does allow you to keep/change the DBNAME of the database but it doesn't give you a provision to specify which DBID that you would like to have the database on. The problem is all with the DBID getting changed with the RMAN duplicate, when you get to refresh the database. The one and the only solution that I could get to work the backups of the refreshed database with RMAN, was the one I described earlier. If anyone interested, let me know, I'll post the sample run down of the logs for your reference.

Cheers :)
Sam

Hello Sam
Can u post the logs.

Thanks

I have put it as an attachment.

Sam