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: Richard Foote <richard.foote_at_bigpond.com>
Date: Tue, 24 Feb 2004 11:55:14 GMT
Message-ID: <CYG_b.74288$Wa.5710@news-server.bigpond.net.au>


"Ron" <support_at_dbainfopower.com> wrote in message news:So2dnf4YbtlCNafd4p2dnA_at_comcast.com...
>
> Fact #1:
> Database in question is a REAL PRODUCTION database, just went uder
> unsceduled outage and was RECREATED (according to user's original and
later
> messages).

Actually Ron, Fact #1 is that you're a raving looney !!

However, addressing the point above. If it was a "REAL PRODUCTION" database, how come the OP deleted the whole thing and simply recovered the original ? Doesn't sound like a "REAL PRODUCTION db to me.

Ron, for a change, why not have a little think about it. How does "After creating a new partition for the data files, I ran dbca to create new database files" constitute a new "REAL PRODUCTION" db. I don't know if you've ever created a "REAL PRODUCTION" database before, but if you have, surely you would know after running the dbca, you have an *empty* database. A "REAL PRODUCTION" database contains these things called tables and indexes and the such. And these tables and indexes contain a substance known as "data".

Now the OP didn't know how to transfer data from the original database to his new one. Like I said in my last post in this silly thread, how can this therefore be construed to be a "REAL PRODUCTION" database as there is *clearly* nothing in it. This is *proven* by the fact that the OP deleted the damn thing. Let me repeat this slooooowly so you might just pick it up this time. Thiiissss iiisssss proooooooooveeeeen, byyyy theeeee faaact thaaaaaat theeeeee OOOOPPPPPPPP deeeeleeeteeeed theeeee daaaataaabaaaseee.

Therefore FACT #1, this was NOT A REAL PRODUCTION database !!

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

The PRODUCTION database is already down you twit !! The empty database is useless, it has no users, it has no data, it has no value. How by simply running the dbca and creating an empty database can the OP magically convert this to a PRODUCTION database ? It needs data from the original database for it to have a chance of claiming such a status but the OP *clearly* said he didn't know how to move the data across. Why has *everyone else* picked up this obvious point, except yourself. It's embarrassing.

So to minimize DOWNTIME, we need to recover the *real* PRODUCTION db ASAP. Your advice will only delay this fact and *increase* the DOWNTIME.

Therefore FACT#2, to minimize DOWNTIME, restore and recover the REAL PRODUCTION db ASAP

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

Yes it does because the actual PRODUCTION database is down and unavailable while we transport across the data to the new DB which until it contains all the necessary PRODUCTION objects is useless to any PRODUCTION users !!

Therefore fact # 3, having the production database down whilst transporting production objects to an unnecessary new database delays and increases DOWNTIME !!
>
> User would be 100% succesful usign TSPIRT (you recognized this as well)
> and he also would keep user experince at a much higher level.
>
> I beleive you assumed that user's database can be manipulated at will
and
> this is why you advice him to do so.
>

As I mentioned in my first post in this silly thread, your TSPITR solution partially recovers a specific tablespace in a second database after cloning a third. When all that was required was to completely recover the original database !!

Ron, guess what. The OP completely recovered his original database and quite happily deleted his unnecessary second database.

And the most remarkable thing of all, you still insist you're right !!

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

Fact #4, Ron, you keep insisting your patient should amputate his leg despite the fact your patient keeps telling you he only has a headache. As such, you're an embarrassing fool ...

And it's on this basis that this thread should end.

However, may I please make one small request. Rather than use your awful disclaimer, can you please end your posts with the following:

It's goodnight from me
And it's goodnight from him
Goodnight

It would put your posts in better perspective ...

Richard Received on Tue Feb 24 2004 - 05:55:14 CST

Original text of this message

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