avoiding corrupted block (ora-01578)

Hi people,

    We are new (6 months) to oracle database and get hit by data block corrupted 5 times over 4 instances of databases. ( should we hire another dba who have a better luck ? ;) One of the interview question will be when is your last encounter of corrupted block ...) Oracle support fax us the steps on how to recover to best as it could, we framed the pages on the wall for easy information access and fear that the paper will get corrupted also.

    Let's get serious.

    We can't live on like this any more, too much resources and people effort ( from operators to sysadms to dbas to developers to help desks to end users ) involve to do recovery. Before we finish one, the other one pop up. We definately need your advices, suggestions. Thanks in advance !

    The REAL questions I want to ask are,

1. How can we scan any potential bad block before writing into it without too much overhead.
2. We are using IBM SSA raid 5, is this a bad choice ? No error report from ssa. After getting a corrupted block, we still able to " cp /.../.../data.dbf /tmp" ( data.dbf contain the table space which contain the corrupted tabe ), can I conclude that nothing wrong on the file from os point of view, nothing wrong with the hardware, the corruption is in the content of the file. If the hardware and the os is not causing the problem, why can't Oracle solve the problem ?
3. Under what circumferances that there is a high chance to get this problem ? too many extent ? too big, too small db_block size ? too many user doing read write for too long ?
4. for people who had encounter similar problem, what platform, os, type of disk, type of disk system, oracle version are u on ? Just want to find out is there any consistent pattern.

    Oh, I almost forgot, we are on AIX 431, oracle 733, SP high node, SSA raid5, SSA hard disk.

    I am sorry to have so many "?" mark in my posting, I am desperate and it also reflect the situation we are in now. Once again, thanks in advance !

Regards
Nathan Phan

Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't. Received on Sun Jun 06 1999 - 21:34:58 CDT