RE: unhacking file$

John,

LOL!!!!  "failed to mention".  That's an understatement.

You are in a world of screwage.  I would throw in the towel right now.
Export the data from the tablespace and hope it all comes out without
issues.

Export the data
Drop the tablespace.
Create it new.
Re-import.

Or - try and create new copies of everything that is in that tablespace
into a new tablespace 
(like create table newstuff tablespace newtablespace as select * from
stuff).  This might be faster than exp/imp.  Then drop the old
tablespace, rename or move the objects back to the newly created
tablespace and off you go.

Truthfully, you should be speaking with Oracle support right now.  They
might be able to help you.  Luckily they don't charge for SR's you
supply them - just post them on the wall under the title 
"Look what *this* guy did"!

Sorry to have a laugh at your expense.  But you are close to losing
everything.  You need to take it seriously and get out of this box you
are in.

Good Luck!

Tom

 
-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx
[mailto:oracle-l-bounce@xxxxxxxxxxxxx] On Behalf Of john d parker
Sent: Tuesday, February 21, 2006 2:51 PM
To: mark.powell@xxxxxxx; oracle-l
Subject: RE: unhacking file$

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@xxxxxxx> 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


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


Other related posts: