Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> c.d.o.server -> Re: rman recover/restore from backup

Re: rman recover/restore from backup

From: Ron <support_at_dbainfopower.com>
Date: Fri, 20 Feb 2004 00:19:02 -0800
Message-ID: <K6ydne-vvon6XKjd4p2dnA@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.

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.

User asked how TABLESPACE (not DATABASE) can be recovered and moved to the new database.

 TSPIRT was one of the options to follow (most valid IMHO)

 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).

As Mr. Howard was saying, he assumed that this database that can be dumped and manipulated at will.

 User did not mentioned a word about such a wild guess (please check the original post).

Quite contrary - he asked how TABLESPACE (not DATABASE) can be recovered and moved to the new database.

From my side I assumed this is a production database and should not be played with any more.

Did you ever recover tablespace using TSPIRT approach Mr. Howard? Can it be done? or it's all damn Oracle lies?

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)

But anyone who can read can check and verify everything what I wrote.

Regards,

  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:40350cc9$0$4260$afc38c87_at_news.optusnet.com.au...
>
> "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 Fri Feb 20 2004 - 02:19:02 CST

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US