| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Usenet -> c.d.o.server -> Re: RMAN Incomplete Recovery question - REPOST
Thanks, Howard. In cricket, India won a test match in Australia after
23 years, so bear with me if I sound too stupid. Blame the alcohol in
me! I did some testing.
Test1: WITHOUT restoring the controlfile
RMAN> run {
2> allocate channel c1 type disk; 3> allocate channel c2 type disk; 4> set until time 'Dec 17 2003 09:13:00'; 5> restore database; 6> recover database; 7> }
Failed with the following error (after restore/before recover, it looks).
RMAN-03022: compiling command: ISW RMAN-03023: executing command: switch RMAN-03026: error recovery releasing channel resources RMAN-08031: released channel: c1 RMAN-08031: released channel: c2 RMAN-00571: =========================================================== RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS
RMAN-00571: =========================================================== RMAN-03002: failure during compilation of commandRMAN-03013: command type: restore
RMAN> run {
2> allocate channel c1 type disk; 3> allocate channel c2 type disk; 4> set until time 'Dec 17 2003 09:13:00'; 5> restore controlfile to '/tmp/junk.ctl'; 6> replicate controlfile from '/tmp/junk.ctl'; 7> sql "alter database mount"; 8> restore database; 9> recover database;
Successful. Was able to do "alter database open resetlogs".
If RMAN were to indeed take care of the controlfile issue for me, why did my recovery fail in Test1? If we use the current controlfile, as I said in the original post, how'd it know about the droppped tablespace and may be that's why recovery failed? I seem to be missing something very basic here (yep, blame it on Jack Daniels). Thanks in advace for your help.
"Howard J. Rogers" <hjr_at_dizwell.com> wrote in message news:<3fdfb987$0$18694$afc38c87_at_news.optusnet.com.au>...
> Without going into the particular scenario in great detail, remember that
> the command you'd issue in RMAN would be:
>
> set until time '9am several weeks ago';
> restore database;
> recover database;
>
> At no point do you even have to worry about whether to restore the old
> control file, because RMAN will work that one out for you. The Oracle
> documentation is correct, however, to say that your database would be in the
> mount state (using the current controlfile) because unless it's in that
> state to begin with, you can't even begin to issue RMAN restore and recovery
> commands.
>
> Regards
> HJR
> --
> ------------------------------------
> Oracle insights at www.dizwell.com
> ------------------------------------
>
> "Ravi Sista comcast_dot_net>" <rsista1_at<remove_this> wrote in message
> news:h_CdnQ8iLYGjLkKiRVn-sQ_at_comcast.com...
> > Still looking for a response. Anyone? Thanks in advance.
> >
> > From: "Ravi" <ravisista_at_hotmail.com>
> > Subject: RMAN Incomplete Recovery question
> > Date: Friday, December 12, 2003 12:26 PM
> >
> > Oracle 8.1.7.4.0 64bit + Sun Solaris 2.8 (Both target and Recovery
> > catalog databases/servers)
> >
> > I was reading the RMAN documentation and got a question regarding
> > Incomplete Recovery with a Recovery catalog. As per the example
> > scenario (steps 2 & 3) at
> >
> <http://download-west.oracle.com/docs/cd/A87860_01/doc/server.817/a76990/rma
> > nreco.htm#437072>
> > , and I quote
> >
> > "2.If the database is open, shut it down and then mount it:
> >
> > shutdown immediate;
> > startup mount;
> >
> > 3.Determine which time you want to recover to. For example, if you
> > discover at 9:15 a.m. that a user accidentally dropped a tablespace at
> > 9:02 a.m., then you can recover to 9 a.m.--just before the drop
> > occurred. You will lose all changes to the database made after that
> > time. "
> >
> > When the tablespace got dropped at 9:02, the database structure
> > changed. In step 2, by starting the database in mount state, we're
> > using the *current* controlfile which doesn't have info about the
> > dropped tablespace. Can you really go back to 9am when the structure
> > was different using this controlfile? I'd have thought the correct
> > procedure would be to
> >
> > * startup nomount
> > * set until time to 9am, restore controlfile from previous backup
> > * alter database mount
> > * restore/recover database
> > * alter database open resetlogs
> >
> > So either the RMAN documentation missed something or I am being stupid
> > here (which wouldn't be the first time). Howard R., this should be a
> > piece of cake for you :-)
> >
> > This brings up another question. How do we make sure which
> > controlfile to use (current or backup) in incomplete scenarios like
> > this. Say someone asked me to restore back to 2 months from today,
> > how would I know whether to restore the old controlfile or use the
> > current controlfile. It looks like I can get away without restoring
> > controlfile if no structural changes happened in the in the past 2
> > months (datafiles/tablespaces/redologs added/dropped). Ofcourse, one
> > hard way to learn is wait till the restore is complete and if the
> > recovery bombs then obviously I have the wrong controlfile. But there
> > MUST be a better way to know about this prior to starting
> > restore/recovery. Is it "report schema"? Or ??
> >
> > Thanks in advance.
> >
> > Ravi
> >
> > --
> > ---
> > Regards,
> > Ravi Sista
> >
> >
Received on Wed Dec 17 2003 - 08:47:01 CST
 |
 |