Oops. Looks like Howard is gone till next year. Anyone else wants to
take a shot at this? Your help is much appreciated. Thanks.
ravisista_at_hotmail.com (Ravi) wrote in message news:<2724afff.0312170647.31e9b3df_at_posting.google.com>...
> 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.
>
> * Did a full RMAN backup at 9:10am.
> * Dropped a tablespace at 9:16am.
>
> Test1: WITHOUT restoring the controlfile
>
> * shutdown normal, startup mount (hence using current controlfile).
> * Tried PIT recovery to 9:13am using the following syntax.
>
> 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 command
> RMAN-03013: command type: restore
> RMAN-03006: non-retryable error occurred during execution of command:
> ISW
> RMAN-07004: unhandled exception during command execution on channel
> default
> RMAN-10035: exception raised in RPC: ORA-19654: must use backup
> controlfile to switch file incarnations
> RMAN-10031: ORA-19654 occurred during call to
> DBMS_BACKUP_RESTORE.SWITCHTOCOPY
>
> Test2: WITH restoring the controlfile:
>
> * shutdown normal, startup nomount.
> * Tried PIT recovery to 9:13am using the following.
>
> 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;
> 10> }
>
> 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 - 13:15:59 CST
