Re: rman recover/restore from backup

"Ron" <support_at_dbainfopower.com> wrote in message news:<j66dnZuYfIrfP6fdRVn-tA_at_comcast.com>...
> Hello Howard,
>
> Quite opposite. I do read. You do interpret.
>
> Read *WHAT user said:
>
> >>>>>>>>>>>>>>>>
> #1:
> "After creating a new partition for the data files, I ran dbca
> to create new database files. I would like to get the users tablespace
> stuff out of the backups and put it into the new database that was
> created by dbca.
> The docos are pretty confusing about all of this. Is there
> not some way to basically take the .bck files, extract the users
> tablespace and put it into the existing database? Sort of like what
> you might do with import?
> Thanks."
>
> #2:
>
> "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)"
> >>>>>>>>>>>>>>
>
> Anything is not CLEAR? Does this looks like a question on HOW to RECOVER
> database? Does this say I can TRASH database at will?

Be very careful in what you write. You are actually asking (or ought to be) "Does this say I can trash THE NEW database at will". To which the answer is undoubtedly and indubitably: yes.

Why won't you even accept the original poster's own response to this group? He trashed his new database, AND HE IS HAPPY TO HAVE DONE SO.

Is it too much for you to acknowledge that you English comprehension is not exactly top-notch, and that you misunderstood what the OP wrote?

You are also quoting wildly out of context. As I replied to the original poster, when he said "This" is a development database, he meant the *original* database was the development database, not the new one he created.

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

OK, I tried. I really tried to give you some credit. But you behave like a moron and reply like a buffoon. Anyone, with even the slightest comprehension of written English, can tell from the OP's contributions here that what was *LOST* was a production database. What I told him to get rid of was a new database he'd created in the hope it might help with not a jot of data in it. You simply refuse to back down, don't you? Richard tells you. Daniel tells you. Normal tells you. Brickeln tells you. Joel tells you. Ana tells you. I tell you.

Me I accept you will ignore. But *all* these others, too?????

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

Odd then that my advice GOT it back!

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

That's "dire" to you.

> User was very LUCKY to be able to follow your advice that required him to
> dispose NEW database and start recovery again.
> In many places doing this he would risk his career.

Same old broken record. I tried. I did try. But you won't have it. I have no idea why, unless you happen to be a paid assistant to the Burleson's of this world.

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

This is complete and utter bollocks. And not because I say so. But because THE ORIGINAL POSTER SAYS SO. HE RECOVERED HIS DATABASE, ENTIRE AND WHOLE WITHOUT ONE WHIF OF TSPITR. So what you are posting is complete and utter crapola.

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

When will you get the message. HE DIDN'T HAVE A PRODUCTION DATABASE. HE HAD A NEW DATABASE WITH NOTHING IN IT AND A PRODUCTION DATABASE LOCKED UP IN RMAN BACKUP SETS.
> Anything else that requires additional production downtime is RECKLESS!
>
> Hope you can face these facts.

Funny ha ha. When *you* will face that you are a pig-ignorant buffoon trotting out text-book answers in complete disregard for what people actually ask, maybe I'll consider it.

You really are an embarrassment to your company. Received on Tue Feb 24 2004 - 06:31:45 CST