| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Mailing Lists -> Oracle-L -> RE: corrupt datafile
Terry - I think you are correct. I believe the minimum you need is the
system tablespace and the lost tablespace. I don't think you can ever open
the lost tablespace otherwise. Frustratingly close though. Anyway you've
received better advice from Tim. People issues are often key in these
situations, but you sound like you've some insights to that.
Dennis Williams
DBA
Lifetouch, Inc.
dwilliams_at_lifetouch.com
-----Original Message-----
From: oracle-l-bounce_at_freelists.org
[mailto:oracle-l-bounce_at_freelists.org]On Behalf Of Terry Sutton
Sent: Saturday, June 12, 2004 4:53 PM
To: oracle-l_at_freelists.org
Subject: Re: corrupt datafile
Dennis,
I don't think a TSPITR will help, because we don't have continuity between datafiles from different times. Most datafiles are from Thursday's backup and one is from Wednesday's backup, and we don't have archivelogs in between. For TSPITR we'd need backups from a point in time prior to the desired recovery time. Unfortunately the ONLY backup file we have from Wednesday is the one for the now-corrupted file.
We do have everything on another server, so we can experiment there, but I can't see how it would work.
Cheers,
Terry
> Terry - You may want to consider a TSPITR. Tablespace Point-In-Time
> Recovery. Do you have another server that you can perform this on? Then
> export/import the data back to your production system.
>
>
>
> Dennis Williams
> DBA
> Lifetouch, Inc.
> dwilliams_at_lifetouch.com
>
>
>
> -----Original Message-----
> From: oracle-l-bounce_at_freelists.org
[mailto:oracle-l-bounce_at_freelists.org]On
> Behalf Of Terry Sutton
> Sent: Saturday, June 12, 2004 3:22 PM
> To: oracle-l_at_freelists.org
> Subject: corrupt datafile
>
>
> A new client has a serious corruption error. During a hot backup (not
RMAN)
> Thursday morning it was discovered that a datafile was corrupted on the
> disk. When the database is started up, the following error occurs:
>
> "ORA-01122: database file 5 failed verification check
> ORA-01110: data file 5:
> '/ora2/app/oracle/admin/dbn/data/dbn_data_01.dbf'
> ORA-01251: Unknown File Header Version read for file number 5"
>
> When dbverify is run against this file, every block is indicated as
corrupt,
> which isn't surprising.
>
> We have a copy of the datafile from Wednesday's hot backup, but they don't
> have the archivelogs necessary to sync this datafile with the rest of the
> database. And we don't have the other datafiles from Wednesday's backup,
so
> we can't just go back to the state the database was in then.
>
> Any ideas on what they can do? I can't think of anything (other than
going
> back to an export they have from 6 months ago, which seems to be the only
> historical backup they have).
>
> --Terry
>
> ----------------------------------------------------------------
> 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
> -----------------------------------------------------------------
>
>
-- Archives are at http://www.freelists.org/archives/oracle-l/ FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html ----------------------------------------------------------------- ---------------------------------------------------------------- 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 Sat Jun 12 2004 - 18:33:37 CDT
 |
 |