Re: Corrupted dbf file... help!!

On Sep 14, 1:10 am, Anurag Varma <avora..._at_gmail.com> wrote:

> Going back to your original suggestion, running strings on a
> controlfile
> might not actually show the datafiles that are being used by the
> database.
> I tried your suggestion on an active database I have and strings
> showed
> me datafiles belonging to tablespaces that had been dropped many
> months back.

Yup, that could indeed be the case.
Let me ask you a question:
do you know for sure the OP would have done that level of manipulation to this database? Kinda hard to believe, when the diff between "ax5" and "ax5.old" is hard to grasp to begin with, eh?

> That leads me to believe that the output of strings *might* confuse
> the OP
> more than helping him/her.

How do we know that is the case in this instance? It's obvious this is a very simple, basic database, \ I actually suspect it's never had anything added or dropped. Otherwise the dba would know for sure what to do.

So please, can we drop the wild "what if" speculation and concentrate on the ACTUAL environment?

Otherwise pretty soon we're gonna be covering the subtleties of doing a strings on a RAC database with ASM over a NFS connection to a USB-key based storage after 12 years of operation in a partitioned DW environment.

Or something...

Which has NOTHING to do with the case
in question, means absolutely nothing in the context of the OP and will only terminally confuse any noobs unfortunate enough to be listening in?

Why is it so hard to accept that there are processes easier and faster and safer
done with a simple, well defined and
documented OS command? Unlike the
stupid and demented insinuation that it is somehow some form of "trickery"?

Of course some subscribe to the notion
that when using Oracle, the only thing that one should touch and think and breathe
is Oracle. Deranged, but possible.,.. Received on Thu Sep 13 2007 - 16:50:55 CDT