Re: rman recover/restore from backup

Hello Richard,

  And to feel good about yourself lets curse - it makes you feel good and brings discussion to the new technical level.

  Don't try - I would not answer with curses back.

  All what you wrote about was already asked and clearly explain and answered.

  But.. Round and round we go. and Round and round we go.

  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:CYG_b.74288$Wa.5710_at_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 - 11:04:29 CST