Re: rman recover/restore from backup

"Ron" <support_at_dbainfopower.com> wrote in message news:Qf6dnYFJRYxHSqjdRVn-uw_at_comcast.com...
>
> Mr Howard,
>
> >How do you begin TSPITR when you have no data files, no
> >control files, no redo logs and only a bunch of RMAN backups to play
with??
> >How do you extract his USERS tablespace, without which TSPITR can't even
> >start.
>
> Why don't refer to metalink instead of asking redundant questions?
(note
> 60545.1 How to Extract Controlfiles, Datafiles, and Archived Logs from
RMAN
> Backupsets for example)

Did you actually read the article? Because one of the first lines in it reads:

"The first stage is to extract the controlfile from a backupset"

You might compare that with what I recommended:

"have another read of the doco. on how to perform disaster recovery with RMAN. It *is* quite involved, but the trick is to get your control file back first"

I notice too that the article to which you refers mentions TSPITR not once. Odd that, don't you think?

I think you should have just pleaded the 5th.

HJR
> >
> > They have. Bricklen, Norman, Richard, Sybrand... they've all spotted
that
> > you haven't a clue.
> >
>
> I would not put Norman that soon in "your" team - He suggested very nice
> resolution to this mess (I hope).
>
> In regards to others - they mostly moral support (which you probably
need).
>
> Ron
> DBA Infopower
> http://www.dbainfopower.com
> Standard disclaimer:
> http://www.dbainfopower.com/dbaip_advice_disclaimer.html
>
>
>
>
> "Howard J. Rogers" <hjr_at_dizwell.com> wrote in message
> news:4035cc0c$0$14898$afc38c87_at_news.optusnet.com.au...
> > You are in a minority of one on this, Ron. One.
> >
> > "Ron" <support_at_dbainfopower.com> wrote in message
> > news:K6ydne-vvon6XKjd4p2dnA_at_comcast.com...
> > >
> > > I guess, this is no use, but maybe this will help someone aside of Mr.
> > > Howard.
> > >
> > > TSPIRT - Oracle recommended procedure to perform tablespace
> point-in-time
> > > recovery.
> >
> > It is indeed practically the only way to perform a tablespace point in
> time
> > recovery: that's what the name means, after all, even if you can't get
the
> > abbreviation of it right. Just a shame that our user didn't want to
> perform
> > a tablespace point in time recovery.
> >
> > > If docs are not 100% clear - metalink has more than enough examples on
> > this
> > > technique (using RMAN, without use of RMAN, etc).
> > >
> > > The fact is that the user lost a database and created a new one.
> >
> > Correct.
> >
> > > User asked how TABLESPACE (not DATABASE) can be recovered and moved to
> the
> > > new database.
> >
> > So answer the question. How does he extract his tablespace out of his
RMAN
> > backups?
> > I'll give you a clue: only RMAN can extract stuff out of an RMAN backup
> set.
> > And RMAN won't work without a control file. And you might note that the
> user
> > didn't *have* any control files to hand.
> >
> > > TSPIRT was one of the options to follow (most valid IMHO)
> >
> > Uh huh. As I said, a minority of one.
> >
> > > Reasons are: No service interruption to the newly created database -
> > which
> > > in fact was a REAL database, not a toy one (check the recent user
> message
> > > again).
> >
> > I did. And I clarified it with him. The original database was only a
> > development one which could stand a bit of data loss. And the new one
had
> > NOTHING in it. Nada. Zilch. Zip.
> >
> > > As Mr. Howard was saying, he assumed that this database that can be
> dumped
> > > and manipulated at will.
> >
> > I assumed nothing, Ron. I can read.
> >
> > > User did not mentioned a word about such a wild guess (please check
the
> > > original post).
> >
> > He didn't have to say it. It was evident in everything he wrote. He
> created
> > a brand new database thinking that he could somehow plug USERS into it.
> > Brand new databases don't have anything in them.
> >
> > > Quite contrary - he asked how TABLESPACE (not DATABASE) can be recover
ed
> > and
> > > moved to the new database.
> >
> > Answer the question Ron: how does he begin extracting his tablespace out
> of
> > his RMAN backups?
> >
> > > From my side I assumed this is a production database and should not be
> > > played with any more.
> >
> > Well, you assumed wrong then, didn't you. And whatever your assumptions:
> how
> > does the guy even begin starting TSPITR when he has no data files, no
> > control files, no redo logs, and only some RMAN backups?
> >
> > > Did you ever recover tablespace using TSPIRT approach Mr. Howard? Can
it
> > be
> > > done? or it's all damn Oracle lies?
> >
> > I have done it frequently, actually, though not often in a production
> > environment. With exports and flashback and log miner, the need for a
> TSPIT
> > is rather rare these days.
> >
> > > We definitely disagree on this and you are definitely not happy with
my
> > > comments (Who cares that I was trying to stop this mess from point
zero)
> >
> > You weren't trying to stop it. You were trying to stir it. You offered
> crap
> > advice in other threads, and thought you'd prove how clever you were in
> this
> > one by mentioning an elaborate recovery procedure that had no
> applicability
> > to the problem at hand.
> >
> > I can argue this one till the cows come home, but why won't you answer a
> > simple question? How do you begin TSPITR when you have no data files, no
> > control files, no redo logs and only a bunch of RMAN backups to play
> with??
> > How do you extract his USERS tablespace, without which TSPITR can't even
> > start.
> >
> > > But anyone who can read can check and verify everything what I wrote.
> >
> > They have. Bricklen, Norman, Richard, Sybrand... they've all spotted
that
> > you haven't a clue.
> >
> > HJR
> >
> >
> >
>
>
Received on Fri Feb 20 2004 - 04:33:02 CST