Removing old backups from earlier incarnation

Question

After a reorg of a database and subsequently getting a new DBID in the repository, I now have a few old backups that I seem unable to reach through RMAN. I can see them on the directory, but since they belong to another DBID, I can't list them.
Am I right in believing that I have to take down the database to be able to change the DBID back to the ID of the old database, just to be able to list and delete the old backups ?
If I want to do it the right way, that is. I could of course just do a rm on the directory where they are, and forget about the whole thing, but that's not what I was aiming for.
This is in a production environment so I'd rather not take down the database unless I really need to.

Answer 1

There are, on disk, several more backups, belonging to one of the incarnations of DBID 2223964660, and I want to delete those the "proper way", by letting RMAN do it. That way I don't have to delete it the by the means of the operating-system, since RMAN will delete it both from disk AND catalog.
Now to the tricky part - how do I do it ?
I tried the thing that Don wrote, without much luck. First of all I need to connect to BOTH the rman-catalog AND the target-database in order to be able to do the "LIST INCARNATION". If not, it keeps telling me "NOT CONNECTED TO TARGET DATABASE".
Once connected to both of them I can list the incarnations, but I cannot do SET DBID=x (RMAN-06188: cannot use command when connected to target database). I can however connect to the RMAN-catalog and then set the DBID, but then I get the next nice error-message saying "RMAN-06189: current DBID 2223964660 does not match target mounted database (2233206566)".
I then tried to do the next command "reset database to incarnation x", which seems to go OK, at least there's no error, but I still turn up with the RMAN-06189 when trying to list incarnations.
Next thing I tried was the tip from Kristin. Logging into the RMAN-catalog (RMAN81) I found only 2 of the three incarnations:
SQL> select * from rc_database;
DB_KEY DBINC_KEY DBID NAME RESETLOGS_CHANGE# RESETLOGS_TIME
1 2 2223964660 OPXP817 1 05-OCT-2001
20208 20209 2233206566 OPXP817 1 19-JAN-2002
That ought to mean the incarnation no 20199 listed in the first "LIST INCARNATION" at the top of this reply, is a fake?
It does not exist, which in turn means that the old backups I have on my disk must belong to incarnation 2.
So, I'm back to the old problem. I cannot set my DBID to 2223964660 and reset the database to incarnation 2 and then try
to list the incarnations. It just doesn't work, and since that doesn't work, I will not be able to tell RMAN to delete the old backups for me. I could of course do what Kristin says. Uncatalog the old incarnation and delete the backups on OS-level, and it sure looks right now as if that is what I'll have to do. Unless someone comes up with a more clever idea that is.Your DBINC_KEY's for Database 2223964660 are 2 and 20199. You need to reset your key to either 2 or 20199 to delete the backups from these incarnations. Your output is kind of interesting since there are 3 entries and 2 DB_KEY's for the OPXP817 DB. It looks like you either recreated or duplicated your database and registered it in the catalog again, and that is why you see 2 entries in the RC_DATABASE view. RMAN sees your new/duplicated database as a separated one from the 2 older incarnations. Usually it would be 3 entries and 1 DB_KEY in the incarnation listing since they all have the same DB_NAME. As for the RC_DATABASE view, that view will give you the databases that are registered in the catalog NOT the incarnations of the database(s). The RC_DATABASE_INCARNATION view will show you all your database incarnations. If your DB with DB_KEY 1 is shutdown you may have to restart it to delete our backups. Hope this helps.