Re: Help with database corruption issue

From: Frits Hoogland <>
Date: Sun, 5 Aug 2012 18:52:46 +0200
Message-ID: <961748657244867016_at_unknownmsgid>

Please mind checking most journalled file systems will ONLY check metadata, not the data itself. Ext3 can be configured to have a journal for data writing (journal mode = ordered). Most filesystem related Linux messages/errors I've seen where due to memory corruptions, not disk corruptions. But that could have been coincidence or bad luck.

Frits Hoogland
cell: +31 6 53569942

Op 5 aug. 2012 om 05:25 heeft Steve Montgomerie <> het volgende geschreven:

> Thanks List!
> Dennis and Peter,
> We could start 19 of 20 databases. When we tried to start database X,
> it would lock up the mount point,
> would not open, and would hang all of the other 19 databases.
> The actual error points to software corruption. Something like running
> fsck against a mounted file system.
> SA swears he did not do that we believe him.
> In regards to the error it points to s system utility that detects a
> bad block and then tries to fix it which ends
> up with the header information being zeroed out of some blocks.
> The only thing that makes sense to me, is that the CP command somehow
> rebuilt the header information
> of the bad blocks. Is that possible?
> On Fri, Aug 3, 2012 at 6:49 AM, Peter Hitchman <> wrote:
>> Hi,
>> Well for some reason the ext4 file system had errors, leading to lost
>> data. That impacts the undo tablespace data file and Oracle could not
>> recover. All I can think is that at some point in time the ext4 file
>> system was not 100% OK and then when you made the data file copy is
>> had been fixed. What sort of disk layout do you have, maybe the error
>> was corrected by way of a disk mirror or some other RAID set-up
>> protection?
>> Regards
>> Pete
>> --
> --

Received on Sun Aug 05 2012 - 11:52:46 CDT

Original text of this message