Re: rman recover/restore from backup

"Ron" <support_at_dbainfopower.com> wrote in message news:Wo-dnd37S8-omKjdRVn-hg_at_comcast.com...
>
> Hi again Richard as well,
>
> Enjoying your posts probably as much as you mine ;-).
>
> If you'll read user's post again you can very clearly (unless you don't
> want to) read that users asking (TWICE) for a way of moving tablespace to
> the new database.

I have tried to explain this to you before, but I'll try one more time. The user asked whether there was a way of extracting his tablespace out of his RMAN backups, and plugging it in to his freshly-created but otherwise blank database.

So, before going any further: can you please explain how you would go about extracting a tablespace out of an RMAN backup?

> TSPIRT is the exact, ORACLE recommended way to do this - want to argue?
> (then refer to Oracle docs first)

TSPITR is Oracle's suggested way of recovering a tablespace to a point in time prior to where the rest of a functioning, full database has gotten to. Our user had no functioning, full database that he was seeking to preserve. He had a new database with nothing in it which he had just created, for some reason thinking he might be able to pull something out of his RMAN backups and plug it into this new database.

Not only therefore was TSPITR not applicable, it wouldn't have actually satisfied the user's requirements.

>
> Mr. Howard advised user to dump his new database and read docs on
> recovery. Yes - user was able to recover database following Mr. Howard's
> advice. No questions about that.

Oh well. That is progress of sorts. At least you finally acknowledge that the user actually got the result he originally asked for by following my advice.

>He would have the same success bringing
> tablespace back using TSPIRT, if he would follow my advice.

No he wouldn't. Answer the first question I posed again. How do you go about extracting a tablespace from an RMAN backup?

> In a process of recovery however, he probably wiped out newly created
> database.

And the awfulness of his doing so was... what, exactly? If you carefully read his post, you will note that there was nothing in that new database, that it had been created in an attempt to "do something", but with no clear idea of what or why. If you read our user's eventual update, you will note that he did indeed wipe out his newly created database, and was no poorer nor sadder for the experience.

> Being a real (not paper) Oracle DBA answer that - is this what you
would
> do or advise anyone to do in production environment for a production
> database?

I can't speak for Richard (though he has already made himself clear on the point). The newly-created database was *not* our user's "production database". It was something he knocked up hoping it might work or help. The production database was locked up inside his RMAN backups. He needed advice on how to get his production database back, not on how to use two functioning databases to perform a TSPITR.

Had our original poster said "I've created a new database using dbca, and I've re-populated it with 100 million rows of data from other sources, and there are now 3000 users making use of that database, but I still want to bring back the USERS tablespace to the time it was before the original failure", then I of course would not have advised dumping the newly-created database, and I would very much have advised him to use TSPITR. But that's not what he asked for, and that wasn't the situation.

>Where you think your users or manager's patience and professional
> trust ends?

Their trust extends only so far as the DBAs competence stretches. That competence is measured (in part) by the DBA's ability to diagnose a situation, and to rectify it without major inconvenience to users, and without major loss of data. Your diagnosis of this situation was wrong. I ask you again: how was the user supposed to extract USERS from his RMAN backups? Your proposed rectification measures were inappropriate, and he would have lost data.

> If this is not your toy desktop database - Time to recovery is
> critical.

Actually, knowing *whether* you can recover at all is the proper starting point. Our user didn't know. He does now. Draw your own conclusions.

>Database recovered (or recreated as in this case) - schemas
> recreated, data loaded and applications and users connects and start
> working. Dare to touch it again?
>
> My advice was attempt to help real DBA to resolve real life problem,
not
> to exercise Oracle lab recovery exercise

You really are just here to wind people up, aren't you? No-one reading this thread could possibly construe my advice as being a "lab recovery exercise", for the simple reason that the original poster got his production database back up and running again by using it. Your advice on the other hand was precisely 'pure theory', in that TSPITR sounds like a sexy piece of technology, but actually has no applicability to the practical issues at hand. One more time Ron: how do extract a tablespace from an RMAN backup?

I can't think of another time when a more blatant attempt to say that black is white and white is black has been made here.

You sure your last name's not 'Burleson'?

HJR Received on Thu Feb 19 2004 - 13:21:43 CST