RE: unhacking file$

From: john d parker <orclwzrd_at_yahoo.com>
Date: Tue, 21 Feb 2006 11:51:28 -0800 (PST)
Message-ID: <20060221195128.23424.qmail@web32603.mail.mud.yahoo.com>

I guess I failed to mention one small insignificant detail...

It's been this way since Jan 18th. The problem first manifested it self thru RMAN duplicate. Rman appears to be a bit too smart for itself in that during the final consistency check, Rman matches up the data dict and the control file. It noticed that a file was missing and threw the baby out with the bath water by discarding not only the missing(next to last) file, but the last file as well. So the clone database kinda works until you access extents that are in that last real but needed but thrown away datafile. Ora-600 errors ensue. Backtracking, I find that a file was added to production with wrong name/wrong tablespace. It was taken offline at that point, they tried to reuse it discovered that they couldn't and well.. you know the rest. About two weeks later I show up on the scene start supporting their systems...

Too much water has passed under the bridge so far. Only simple way is to "unhack" the damage that has been done. If that can't be done reasonably safely, then their entire db must be rebuilt and exp/imp all the data. I loathe exp/imp so "unhack" is my first choice.

John

"Powell, Mark D" <mark.powell_at_eds.com> wrote:

>
> I guess zero change that a commit has not been issued and the
> offending
> session is still open?
>
> Since whatever you are about to do is unsupported I suggest you start
> by
> making an immediate hot backup. If the database is small enough a
> full
> export would not hurt either.
>
> You did not mention production or test, etc.... You might consider
> restore and point in time recovery.
>
> HTH -- Mark D Powell --
>

Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

--
http://www.freelists.org/webpage/oracle-l

Received on Tue Feb 21 2006 - 13:51:28 CST