Oracle FAQ | Your Portal to the Oracle Knowledge Grid |
![]() |
![]() |
Home -> Community -> Mailing Lists -> Oracle-L -> RE: RMAN resync of catalog to controlfile
Sounds do-able and cool, don't have the time right now though...
Maybe in 2 or 3 weeks though...
Let me know what the outcome is...
Clint
-----Original Message-----
Sent: Friday, March 07, 2003 6:09 AM
To: Multiple recipients of list ORACLE-L
A facinating idea Tim.... no time this weekend, but I plan on playing with the idea if someone else dosen't.
RF
-----Original Message-----
To: Multiple recipients of list ORACLE-L
Sent: 3/6/2003 9:23 PM
Joe,
Thinking outside the box a little...
How about if you query the recovery catalog views on RMAN repository database, using a technique of "SQL-generating-RMAN"?
Connecting to the recovery catalog database, you could query the RC_BACKUP_CONTROLFILE view to generate a series of CATALOG CONTROLFILECOPY commands, query the RC_BACKUP_DATAFILE view to generate a series of CATALOG DATAFILECOPY commands, and query the RC_BACKUP_REDOLOG view to generate a series of CATALOG ARCHIVELOG commands. Of course, you'd have to join all these views to RC_BACKUP_SETS and RC_BACKUP_PIECES in order to get the actual filenames/file handle-names as well, so query wouldn't be quite trivial, but nothing too crazy.
So, your queries in SQL*Plus against the RMAN recovery catalog database would spool out a script of RMAN commands. Then exit SQL*Plus and connect to RMAN in NOCATALOG mode to run the generated commands against the target database.
I'd be concerned about the after-effect of doing this when you finally do a subsequent RESYNC CATALOG, but until I get a chance to test this sometime next week, perhaps some enterprising soul might consider giving it a try in a test environment?
What do you think?
-Tim
> the catalog has all of the current backup info, so if i lose the
> repository(before taking a backup after rebuilding the controlfile),
> I'm SOL. I logged a tar and oracle's response is, no way to push
> catalog info back into the controlfile.
>
> joe
>
>
> > Joe - I'm confused. If you rebuild the controlfile, what good is the
> backup
> > information stored in the catalog? Other than maybe deciding to
> revert to a
> > time before the rebuild, and you're going to need the catalog for
that
> > anyway.
> >
> > Dennis Williams
> > DBA, 40%OCP, 100% DBA
> > Lifetouch, Inc.
> > dwilliams_at_lifetouch.com
> >
> >
> > -----Original Message-----
> > Sent: Wednesday, March 05, 2003 8:19 AM
> > To: Multiple recipients of list ORACLE-L
> >
> >
> > Robert, and all of you other RMAN gurus.
> >
> > scenario 1: repository unavailable, so rman backup was done using
> > controlfile only. upon later successful connection to repository,
> the
> > backup info was pushed from controlfile to repository(YEA).
> >
> > scenario 2: I have to rebuild the controlfile and have a rman
> > repository. so i do a resync in rman, rebuild the controlfile and
> > connect back to repository, doing a resync HOPING that the
> controlfile
> > gets updated with info from repository, no such luck. I did a dump
> of
> > the controlfile(via alter session set events 'immediate trace name
> > controlf level 10'), looking for the section on BACKUP SET RECORDS
> and
> > BACKUP PIECE RECORDS and there is nothing there.
> >
> > so my question is this: is the resync only a one way push, i
> > understand oracle's mentality about not overwriting the backup
> records
> > in the controlfile since that should be the true information, but is
> > there a way to force oracle/rman to push the repository info back
> into
> > the controlfile, i've not found a solution for this.
> >
> > if anyone is interested in the dump files, let me know and i'll make
> > them available on the web so you can see what I'm talking about.
> >
> > thanks, joe
> >
> >
> >
> >
> > Joseph S Testa
> > Chief Technology Officer
> > Data Management Consulting
> > p: 614-791-9000
> > f: 614-791-9001
> > --
> > Please see the official ORACLE-L FAQ: http://www.orafaq.net
> > --
> > Author: Joseph S Testa
> > INET: jtesta_at_dmc-it.com
> >
> > Fat City Network Services -- 858-538-5051 http://www.fatcity.com
> > San Diego, California -- Mailing list and web hosting
services
> >
-- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Tim Gorman INET: Tim_at_SageLogix.com Fat City Network Services -- 858-538-5051 http://www.fatcity.com San Diego, California -- Mailing list and web hosting services --------------------------------------------------------------------- To REMOVE yourself from this mailing list, send an E-Mail message to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing). -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Freeman Robert - IL INET: FREEMANR_at_tusc.com Fat City Network Services -- 858-538-5051 http://www.fatcity.com San Diego, California -- Mailing list and web hosting services --------------------------------------------------------------------- To REMOVE yourself from this mailing list, send an E-Mail message to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing). -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Clinton Naude INET: clintonn_at_meb.co.za Fat City Network Services -- 858-538-5051 http://www.fatcity.com San Diego, California -- Mailing list and web hosting services --------------------------------------------------------------------- To REMOVE yourself from this mailing list, send an E-Mail message to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).Received on Thu Mar 06 2003 - 23:23:45 CST
![]() |
![]() |