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 http://fritshoogland.wordpress.com mailto:frits.hoogland@xxxxxxxxx cell: +31 6 53569942 Op 5 aug. 2012 om 05:25 heeft Steve Montgomerie <stmontgo@xxxxxxxxx> 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 <pjhoraclel@xxxxxxxxx> 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 >> -- >> //www.freelists.org/webpage/oracle-l >> >> > -- > //www.freelists.org/webpage/oracle-l > > -- //www.freelists.org/webpage/oracle-l