Re: corrupt datafile
- From: "Terry Sutton" <terrysutton@xxxxxxx>
- To: <oracle-l@xxxxxxxxxxxxx>
- Date: Mon, 14 Jun 2004 09:03:01 -0700
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@xxxxxxxxxxxxx
put 'unsubscribe' in the subject line.
--
Archives are at //www.freelists.org/archives/oracle-l/
FAQ is at //www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------
Other related posts:
