Many THANKS to the following people who all provided helpful tips and
information on how to recover and possible culprits. We have learned from
these notes. We appreciate the information.
Paul Roetman
David J. DeWolfe
Alex Harkema
Eskil Swahn
Gregory Dora
Oracle support provided the following explanation of the cause of the
problem as we were using symbolic links for this particular database.
-------------------------------------------------------------------------
"I did not find anything written on our internal database. I did
verify and we do not support symbolic links for datafiles because they
are not stable. This can cause the ora-1122 error that you received. I
recommend that you specify the full path name, including device name, to
your datafiles in the future to avoid this problem."
----------------------------------------------------------------------------
There is a dbverify script, that will verify each datafile's validity (maybe
called dbv).
Check the alert log - each database will log all events that occur to the
database into an alert log.
Generally, when a file goes corrupt, the "standard" procedure would be to
1. restore a good copy of that particular datafile (not the rest of the
database) - save the old file just in case. I would generally rename the old
datafile, so that the corrupt portion of the disk cannot be reused.
2. recover the database - which will roll forward the restored datafile - it
will prompt for whatever archive logs it needs.
But this would generally be done by an Oracle DBA - it is not something that
you would do lightly. If you have Oracle support, they can probably walk you
through the procedure.
--------------------------------------------------------------------------
Hmmm, that seems pretty bizarre. No OS "events" (crashes etc) during the
period the database was down? Have you checked the date/time stamp of the
datafiles in question versus the control files? In addition to the datafile
being corrupt, the 01122 message indicates that the control file could be
from an earlier time than the data file. Have you tried running the Offline
Database Verification Utility (dbv)? I'm running Oracle 7.3.4 as opposed to
Oracle8 but I would hope that dbv made it to Oracle8. In the Oracle7 world,
you can find info on dbv in Chapter 10 of the Server Utilities manual. I
have a script that reads the output of the "alter database backup
controlfile to trace" command and generates all the dbv commands for you if
you'd like a copy.
Any messages in the alert log?
What did you do to resolve this problem the first time it happened? Have
you tried starting the database when you've encountered these problems? We,
the University of Alaska, did experience datafile corruption several years
ago in the OSF/1 3.2 and Oracle 7.1 days and after that, when we suspected
problems we'd do a full database export to /dev/null. We weren't interested
in the data (we had cold database backups for that) but we were interested
in any warnings generated by the export. Oracle support indicated that a
full database export was the best way to determine if you had a corrupt
database. A few times we got warnings and we then did an "analyze table
<table indicated by export warning> validate structure cascade" and we'd
see messages such as "one row ends in the middle of another". Anyway, that
was several years ago but the point is that once or twice we actually had a
corrupt database that would startup and shutdown just fine but when that
data was actually accessed, the database would go down hard.
-------------------------------------------------------------------------
I saw something alike in Oracle-on-SuSe linux archive:
http://lists.suse.com/archives/suse-oracle/1999-Aug/0055.html
I don't think this'll give you the reason, though...
-------------------------------------------------------------------------
Are you running On-line backups? This can occur if you have missed to get
the tablespaces back online after the backup.
-------------------------------------------------------------------------
Thank you,
Craig Stauber
Acxiom Corporation
CStaub_at_Acxiom.COM
Received on Tue Jul 25 2000 - 17:04:25 NZST