These folks should not blame anyone (or anything) but themselves. They ble=
w
straight through the many fail-safes that Oracle provides, so that any one
of a thousand minor mishaps would have landed them in this exact same
situation. It was just waiting to happen.
My sincere condolences...
-Tim
on 6/12/04 2:21 PM, Terry Sutton at terrysutton@(protected) wrote:
> A new client has a serious corruption error. During a hot backup (not RM=
AN)
> Thursday morning it was discovered that a datafile was corrupted on the d=
isk.
> When the database is started up, the following error occurs:
> =20
> "ORA-01122 (See ORA-01122.ora-code.com): database file 5 failed verification check
> ORA-01110 (See ORA-01110.ora-code.com): data file 5:
> '/ora2/app/oracle/admin/dbn/data/dbn_data_01.dbf '
> ORA-01251 (See ORA-01251.ora-code.com): Unknown File Header Version read for file number 5 "
> When dbverify is run against this file, every block is indicated as corru=
pt,
> which isn 't surprising.
> =20
> 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.
> =20
> Any ideas on what they can do? I can 't think of anything (other than goi=
ng
> back to an export they have from 6 months ago, which seems to be the only
> historical backup they have).
> =20
> --Terry
<HTML >
<HEAD >
<TITLE >Re: corrupt datafile </TITLE >
</HEAD >
<BODY >
<FONT FACE=3D "Arial " > <SPAN STYLE=3D 'font-size:12.0px ' >Terry, <BR >
<BR >
Hopefully they have logged a TAR with Oracle Support and are working it tha=
t way. It is possible that “dbverify” is returning the res=
ponse that every block is corrupt simply because it cannot read the file-hea=
der information, not because the entire file is shredded. This file mi=
ght have a few bytes out of place in the header, in which case it is possibl=
e that Oracle Support’s Data UnLoader (DUL) utility might be able to d=
ump the data from the file. Otherwise, if every single block is corrup=
t, then even DUL probably would not be able to retrieve the data. <BR >
<BR >
A “hot backup” from Wednesday is available but the archivelogs =
going back to that backup aren’t? Other datafile backups from th=
e “hot backup” on Wednesday are not available? It seems th=
at many, many things have gone wrong here. It would be worthwhile to d=
well on why the other datafiles and the archivelogs are not available, so th=
at this never happens again. This is a time for brutal honesty. <BR >
<BR >
