Re: Non-Sql data extraction (recovery tools)

From: Tim Gorman <tim_at_evdbt.com>
Date: Thu, 15 Aug 2013 12:52:35 -0600
Message-ID: <520D2373.2050101_at_evdbt.com>



John,
Having corrupted data is quite a bit different from having a bunch of datafiles without a database instance to open them.

Your database is still up and running, so you still have access to data via the SQL interface. There is no benefit and many risks from bypassing it.

Bypassing the SQL interface is unlikely to help you recover the data in the corrupted blocks. There is quite a bit of documentation in the standard Oracle documentation about dealing with corruption, starting with white papers and then extending through the documentation on the DBMS_REPAIR package and RMAN.

Since you've indicated that you no longer have backups taken prior to the corruption's appearance, then the material involving RMAN is kind of moot, unless you're already planning on how to prevent this happening again.

At this point, you probably want to concentrate on understanding the DBMS_REPAIR package, first to "put a wall around" the corrupted blocks so that table scans don't fail, then attempting to recover or reconstruct the data, if possible. There is a fair chance that the blocks are not just "tweaked" in the header and that the row data is stil available, but that the entire blocks are scrambled, and that nothing can read it.

More on...

Hope this helps...

-Tim

On 8/15/2013 12:22 PM, John Smith wrote:
> Im sorry, I should have made that clear. Im getting errors about
> corruption in my alert log, and ora-600 errors when trying to do
> simple selects and exports. Occasionally I get object no longer exists
> errors also. The last backup is corrupted also.
>
>
> On Thu, Aug 15, 2013 at 1:16 PM, Tim Gorman <tim_at_evdbt.com
> <mailto:tim_at_evdbt.com>> wrote:
>
> One of two things are going on here...
> 1. Performing recovery from a unopenable Oracle database, when
> this is
> the only possible method to extract the data for reload
> * Though it isn't free, DUDE (http://www.ora600.be) is the best
> tool available at the lowest cost
> o if the data is truly of value, then the cost should
> considered in light of the value of the data
> o Extracting data directly from the datafiles for any other
> purpose or reason is foolish
> + Bypassing the consistent-read mechanism built into the
> SQL API of Oracle can yield corrupted data
> 2. Hacking into some Oracle datafiles
> * I am not interested in helping someone do this, both for the
> reasons stated above and because it might be irresponsible
> <SNIP
>
>
> --
> http://www.freelists.org/webpage/oracle-l
>
>
>

--
http://www.freelists.org/webpage/oracle-l
Received on Thu Aug 15 2013 - 20:52:35 CEST

Original text of this message