RMAN catalog out of sync

[marist89]

While testing my backup/recovery strategy, I managed to screw something up.

First, I shutdown the database and made an OS copy of the database. Then, I setup RMAN, ran some backups, ran some restores, and everything was fine. I then made an error on a backup and couldn't restore my database. I then restored my OS copy and the database came up with no problem.

However, now my recovery catalog is out of sync with my database. When I issued "resync catalog", I got an RMAN-20032 "checkpoint change# too low".

Any thoughts on how I can tell my recovery catalog to forget about everthing it already knows and start from the current incarnation of the database?

[sambavan]

login as the catalog user,

RMAN> drop catalog;

RMAN> create catalog tablespace tablespace_name;

exit;

now connect again using the target and catalog

RMAN> register database;

RMAN> resync catalog;


Or just try

RMAN> resync catalog;

Sam

[marist89]

Yeah, I was going to drop the catalog as plan B. I would like to avoid it if possible as I am testing several instances in the same catalog.

I was thinking of recoverying the current database until cancel, immediately cancel, and then open the database resetlogs through RMAN, and then reset the database. Does this sound like it might work?

[marist89]

The second method worked. I recovered the database until cancel, opened resetlogs and then issued the "reset database" command.

[sambavan]

It was your catlogdb/ targetdb?

Sam

[marist89]

Yes, the target db.

[sambavan]

If you don't mind could you post the steps? The point I'm kind of getting lost is when your catalog is out of sync, how would it allow you to open the target, where it would try the sync first before doing anything?

Just curious ....

Sam

[marist89]

1. create database (t1)
2. add data to database (t1)
3. register database (t1)
4. backup database (t1)
5. shutdown database immediate (t1)
6. make an OS cold backup using cp
7. startup database
8. backup database (t1) through rman
9. delete some files testing backup
10. realized that backup didn't contain all the files I needed for recovery.
11. shutdown abort (t1)
12. cp files from OS
13. startup database (t1). Database is now up, but RMAN doesn't know why the checkpoint number is so low. If I issue reset database, rman knows that the database hasn't been opened with resetlogs.
14. shutdown immediate (t1)
15. startup mount (t1)
16. recover database until cancel (t1)
17. cancel
18. open database resetlogs (t1). Since I issued resetlogs, I can now issue the reset database command.
19. use rman and issue reset database command

[sambavan]

The steps 13 through 18 are performed through RMAN/ outside of RMAN?

Originally posted by marist89

13. startup database (t1). Database is now up, but RMAN doesn't know why the checkpoint number is so low. If I issue reset database, rman knows that the database hasn't been opened with resetlogs.
14. shutdown immediate (t1)
15. startup mount (t1)
16. recover database until cancel (t1)
17. cancel
18. open database resetlogs (t1). Since I issued resetlogs, I can now issue the reset database command.
19. use rman and issue reset database command

BTW, thax for posting the steps:

Sam

[marist89]

13-18 are outside of rman.