-
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?
Jeff Hunter
-
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
Thanx
Sam
Life is a journey, not a destination!
-
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?
Jeff Hunter
-
The second method worked. I recovered the database until cancel, opened resetlogs and then issued the "reset database" command.
Jeff Hunter
-
It was your catlogdb/ targetdb?
Sam
Thanx
Sam
Life is a journey, not a destination!
-
-
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
Thanx
Sam
Life is a journey, not a destination!
-
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
Jeff Hunter
-
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
Thanx
Sam
Life is a journey, not a destination!
-
13-18 are outside of rman.
Jeff Hunter
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules
|
Click Here to Expand Forum to Full Width
|