Howard J. Rogers wrote:
> "Karsten Farrell" <kfarrell_at_belgariad.com> wrote in message
> news:954R9.1116$KM.90452994_at_newssvr17.news.prodigy.com...
>
>>ronia wrote:
>>
>>>Supose I have only a datafile data.dbf
>>>I not have system.dbf, redologs.dbf temp.dbf etc.
>>>
>>>Are anyway to recover the data. At least manualy???
>>>I heard that Oracle Consulting can do it.
>>>
>>
>>Hmm. Bad situation. Yes, Oracle Consulting can do it ... they have a
>>tool - actually from the developers - that can read a DBF file as though
>>it were an ordinary O/S file and produce a SQL Loader CSV file. If you
>>are ambitious enough, you could write a similar tool (but I suspect you
>>need to retrieve the data right now ... not 6 months from now when you
>>might finish coding the tool).
>>
>>I doubt the following will work (never tried it myself), but you might
>>give it a go before spending the big money to bring in a Consultant:
>>
>>1. Place your data file (data.dbf) in the directory of another database
>>(create one if you don't have another handy).
>>
>>2. Create a new tablespace in this other db that refers to data.dbf as
>>its datafile. You might have to place it offline for now. If Oracle
>>complains at this point, and you don't know what it's complaining about,
>>call the Consultant.
>>
>>3. Bounce the database. At this point, I expect Oracle will complain
>>about the datafile being out of sync with the control file. Perform a
>>recovery and reset the control file (resetlogs). There will be nothing
>>to recover for data.dbf in the redo logs on this other db.
>>
>>4. If the above fails, call Oracle support. In fact, I'd probably do
>>that anyhow because they might have a solution that they can walk you
>>thru that's more "correct" than my wild guess procedure.
>
>
>
> I like the idea behind your approach, but it isn't going to work. Whilst you
> might be able to fudge a datafile resynchronisation with a resetlogs in this
> way, the OP's data dictionary isn't going to know a thing about the segments
> within the datafile. So getting at the data is going to be impossible.
>
> So I'd leap straight to your step 4.
>
> Regards
> HJR
>
>
I was afraid someone with more knowledge was going to say that. Thanks
for jumping in and correcting my wild guess!
Received on Thu Jan 02 2003 - 19:02:17 CST
