Re: corrupt datafile

From: Terry Sutton <terrysutton_at_usa.net>
Date: Mon, 14 Jun 2004 09:03:01 -0700
Message-ID: <019101c45229$59f32420$0400a8c0@TerrySutton>

Graeme,

Good idea. The client was actually trying stuff along this line, and it's what they're using to get what data they can. Unfortunately they'll lose a pretty significant amount of data, but that's the risk of not having backups.

Cheers,

--Terry

> Terry,
>
> For point-in-time recovery you would also need the RBS/UNDO tablespace(s)
to
> allow incomplete transactions to be rolled back. Moot point considering
the
> spread of datafiles in backups and lack of archive logs.
>
> Based on the premise that some data is better than no data (and the
> assumption that the indexes are in a non-corrupted tablespace), you could
> take the affected datafile offline, open the database and dump the data
that
> is in the indexes into copies of the tables then dump the data to an
export
> dump file. It's not ideal (unless you have indexes that cover all columns)
> but it may help application analysts/management recover a large amount of
> usable data. Or it may not, depends entirely on the coverage/availability
of
> indexes and the relative importance of non-indexed fields (probably
> important or else they wouldn't be there!).
>
> This would often be a reasonable approach for reconstructing small amounts
> of data following block corruption (pre-RMAN blockrecover) but when you
> don't have many options it may be that it saves "some" business data.
>

Please see the official ORACLE-L FAQ: http://www.orafaq.com

To unsubscribe send email to: oracle-l-request_at_freelists.org put 'unsubscribe' in the subject line.

--
Archives are at http://www.freelists.org/archives/oracle-l/
FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------

Received on Mon Jun 14 2004 - 11:03:10 CDT