Re: rman recover/restore from backup

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 recovered
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 - 02:57:47 CST