Re: rman recover/restore from backup

"Ron" <support_at_dbainfopower.com> wrote in message news:<So2dnf4YbtlCNafd4p2dnA_at_comcast.com>...
> > It's about whether *your* method
> >was applicable to the original poster, and whether my not mentioning
> >it was "reckless". The fact remains, unfortunately (for you) perhaps,
> >that the original poster got his database back without using your
> >'method',
>
> Hello Howard,
>
> Fact #1:
> Database in question is a REAL PRODUCTION database,

No that's not a fact. That's a complete invention on your part, as is evidenced by the original posters own contribution here.

> just went uder
> unsceduled outage and was RECREATED (according to user's original and later
> messages).

No, by the original poster's own admission, he didn't REcreate anything. He used DBCA to create a brand new, totally empty database. So that's not a fact either.  

> Fact #2:
>
> Your advice required user to dispose new PRODUCTION database and recover
> old database.

No, my advice was that he dispose of the new database he'd created on the off-chance it might be useful, since he wouldn't need it to actually recover. (NB: oddly enough, the OP disposed of his new database and was able to recover without it. Er, just as I suggested he would).

> Your advice requires DOWNTIME.

His production database was already down. It required no more downtime than he was already suffering.

>
> Fact #3
>
> My advice was to to recover necessary data OUTSIDE of PRODUCTION database
> and bring in in using transportable tablepsaces.

No, your advice was to perform a completely unnecessary TSPITR.

> My advice DOES NOT requires DOWNTIME.

Your advice requires that having recovered what was his production database, he actually endure *more* downtime whilst he goes through the rigmarole of transporting the data OUT of his production database and into a database which otherwise has nothing in it.

> User would be 100% succesful usign TSPIRT (you recognized this as well)

No, I recognise only that TSPITR, which you still can't get the abbreviation right for, was completely and utterly unnecessary. Oh, and so does the original poster, by the way.

> and he also would keep user experince at a much higher level.

He didn't have any users, so dancing on a lampost with a ukele would have achieved a much higher level of user experience too. Whatever it might mean.

> I beleive you assumed that user's database can be manipulated at will and
> this is why you advice him to do so.

No, you can't read English, and your English skills are pretty poor so that's not entirely surprising, and you therefore have no idea or understanding how it is that I managed to work out what was actually going on.

> And on that basis, I also think this thread should end.

Then you're an even bigger idiot than I gave you credit for, because I gave you every opportunity to back up a bit, acknowledge a modicum of common ground and accept only the slimmest of face-saving politeness. And you couldn't even do that.

Everyone in this newsgroup, Ron... and I mean *every*one, knows that what you are prattling on about is utter tosh. And I include Norman in that, and I am sure he will jump on me and this thread if I've mis-understood him.

And here's the thing: if you can't even be half-decent in this thread, then it is abundantly clear that you have *nothing* to offer in any other threads. Even if you happen to strike it technically accurate, it is painfully apparent it will be by pure chance. That's not good for you, for your company, or for the unfortunate schmucks who happen to be in receipt of your advice.

And yes, I know full well that you will plead "Mr Howard is being unkind to me". Try and understand, though: it's not just me. Every even vaguely regular on this newsgroup thinks of you with utter disdain.

> Ron
> DBA Infopower
> http://www.dbainfopower.com
> Standard disclaimer:
> http://www.dbainfopower.com/dbaip_advice_disclaimer.html
Received on Tue Feb 24 2004 - 06:46:02 CST