Oracle FAQ Your Portal to the Oracle Knowledge Grid

Home -> Community -> Mailing Lists -> Oracle-L -> Re: unhacking file$

Re: unhacking file$

From: Michael Haddon <>
Date: Tue, 21 Feb 2006 18:28:12 -0600
Message-ID: <>



If you know the times that each of these deletes happened you could always use the logminer packages to show the sql that was run to perform the delete and access undo sql.

Of course I would definitely plan to recover as stated below, it would probably be supported. The other obvious question would be is "Where is this well meaning DBA now??" It's never a good idea to modify the data dictionary, it used to be the way you could accomplish some tricky tasks but that was more than 10 years ago.


Mercadante, Thomas F (LABOR) wrote:

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

Export the data
Drop the tablespace.
Create it new.

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!


-----Original Message-----
[] On Behalf Of john d parker
Sent: Tuesday, February 21, 2006 2:51 PM
To:; 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.


--- "Powell, Mark D" <> wrote:

I guess zero change that a commit has not been issued and the
session is still open?

Since whatever you are about to do is unsupported I suggest you start
making an immediate hot backup.  If the database is small enough a
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 


-- Received on Tue Feb 21 2006 - 18:28:12 CST

Original text of this message