Re: rman recover/restore from backup

Hello Richard,

   Hope, for a last time:

   Read *WHAT user said*:

"This is a development db so if a few things got lost it was no big deal. Somebody should have said (and in so many words they did)"

   This was a REAL database, real USERS, real LIFE. Development database considered INTERNAL PRODUCTION.

   In a big company you'd have enormous pressure to get it back - both from employees and management.

  If DBA can not recover database and decide recreated it - it is back in use IMMEDIATELY. It is not a TOY. Touch it again - and consequences can be dare.

   If you need some data from the old database - Best you can do is to perform TSPIRT on tablespaces you need and move them to the NEW database.

  Doing TSPITR you DO NOT IMPACT PRODUCTION DATABASE - this is what is important.

 Anything else that requires additional downtime is RECKLESS!

  If this simple logic misses you, that you definitely can be a hero of your own comedy.

Regards,

  Ron
  DBA Infopower
  http://www.dbainfopower.com
  Standard disclaimer:
http://www.dbainfopower.com/dbaip_advice_disclaimer.html

"Richard Foote" <richard.foote_at_bigpond.com> wrote in message news:q8u_b.73233$Wa.65596_at_news-server.bigpond.net.au...
> "Ron" <support_at_dbainfopower.com> wrote in message
> news:uvOdnXDtf7atp6fdRVn-jw_at_comcast.com...
> > Hello Kapiza,
> >
> > The situation is that new database is already created and potentially
in
> > use by users.
> >
> > These steps allow to move tablespace from the old database backup to
the
> > new database.
> >
>
> And dear Ron, that's the problem isn't it ?
>
> In *this* scenario, we have a new database that is *clearly not* in use by
> users. Why, because the OP told us. He said he had just created a new
> database in the hope of getting an operational database again, without
> knowing how to get data across from the old one. Therefore how can this
new
> database be operational, there's *clearly* no data in it. How can users
> logon to the new database when the application doesn't know what customers
> it has, what products it sells, what address to send things too, as the
new
> database has *no* data in it. The OP didn't know how to populate it with
> production data. *He told us* !!
>
> Therefore, to help the OP out, we need to correctly diagnose the problem.
> The problem being his database was stuffed, he lost all his control files,
> help, this is what I've attempted to do. The *solution* therefore was to
> restore the control files and *fully* recover the *original* database. A
> TSPITR is *totally* the wrong way to go, *totally* inappropriate and a
> *totally* inferior solution as I mentioned previously.
>
> And as mentioned by Howard on at least 10 separate occasions, Howard who
> offered the OP the *correct* solution in his *first* post.
>
> However, not only have you never listened to us, you haven't even bothered
> to listen to the OP who *clearly* stated thankyou, *Howard's* solution has
> enabled me to *fully* recover my database without the need for any TSPITR.
>
> You just don't get it do you. And what makes you move from silly to plain
> ridiculous is your refusal to accept your wrong and that Howard was right.
> Instead you accuse him of somehow acting improper and that the OP's
scenario
> is somehow different from "Reality" (the name BTW of the best David Bowie
> tour I've ever seen ;) Again, don't take my word, ask the OP, it was his
> scenario that Howard was trying to help. How did he eventually fix his
> problem ...
>
> A doctor that doesn't listen to his patients and diagnoses the wrong
problem
> and hence provides the wrong medicine is clearly a *bad* doctor who
> shouldn't really be practicing. Same goes for a DBA ....
>
> Ron, read this carefully. I strongly suggest a few little apologises might
> be appropriate to redeem what little reputation you have left, else I fear
> you Ron with Don might become the funniest comedy duo since "The Two
> Ron(nies)".
>
> Cheers ;)
>
> Richard
>
>
Received on Mon Feb 23 2004 - 18:47:13 CST