Data corruption on Linux 2.x/Oracle 8.0.5

Hello

I wonder if I'm the only one experiencing data corruption on Linux based servers, using the 8.0.5 Oracle Enterprise Server. For me it happens really too often.

I have used Oracle for several years now, mostly on SCO ODT/OSR boxes and *never* experienced data blocks corruption, even after bad going fscks.

Using Linux for a couple of years as file server, DHCP, DNS, etc ..., without a glitch, when Oracle officially released a version for Linux, I decided to migrate our Oracle servers to Linux, the Oracle 8 server not beeing ported to SCO OSR, but only to Unixware which I don't want to migrate to (I personnally prefer BDS based systems than SysV ones).

I've had since a *lot* of data block corruption. In rollback segments TS, in redo logs and in tables data. The kernel version seems irrelevent, as I had it both on 2.0.36 and 2.2.9. The glibc version doesn't changes anything I use both 2.0 and 2.1. The type of drives too, as I had the same problems with Megaraid and EIDE drives.

What happened to me yesterday evening is even weirder.

The machine is:

Pentium II/200 Mhz, EIDE drive, 64Mo RAM, kernel 2.0.36 glibc 2.0 (RedHat 5.2), Oracle 8.0.5.

A user call me that a view doesn't return data it should. Doing a 'select count(*)' on it produces an ORA-1578. Dbv utility report 2 influx blocks and one marked corrupted. I re-create the table renaming the bad one and using insert-select skipping the rowids in the corrupted block, then I drop the old table. I do an export of the account which is on the corrupted TS, then drop the user and drop the TS.
I remove physically the file, then recreate the TS then the user. Dbv reports a clean TS.
I start importing the data and then get an error on an index creation with an ORA 1578, same file, but another block. So I shutdown the database, reboot in single user, do a forced fsck which reports nothing bad. I do a non-destructive badblock scan of the potentially faultly partition, no bad blocks are found. I reboot to multiuser, restart the database drop again the TS and the user, remove physically the file then recreate the TS, user and do the import without any problem. Dbv reports me no problem on TS.

On an other box I had the same kind of problem, it seems that shutting down the database and rebooting the system solved too the problem.

As usual, when it happens, the Oracle support is off (10pm) and the server *must* run early in the morning, so it is always emergency procedures, so I haven't really time to track the problem, and even Oracle support responses are to restart and recover the database, not to track the problem.

I'm puzzled: is it a 8.0.5 problem ? A linux/oracle problem ? Anything else ? I don't know :-(

Any thoughts ?

Thank you for reading me,

François Désarménien Received on Thu Nov 04 1999 - 07:32:57 CST