|
John, 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. Mike Mercadante, Thomas F (LABOR) wrote: -- //www.freelists.org/webpage/oracle-lJohn, 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: |
