Re: avoiding corrupted block (ora-01578)

Hi Nathan,

> ...( should we hire
> another dba who have a better luck ? ;)
No because your one is now a professional in this area ;-)

Do you have -perfect- climatic conditions ? I am quite shure you don't shut down your servers for too long, do you?

> 1. How can we scan any potential bad block before writing into it
> without too much overhead.

Isn' there a init<SID>.ora parameter that enables read after write ? (slow) Ask your Oracle support.

> 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

do you have entries in errpt? If yes which ones. Do you have entries in alert<SID>.log. If yes which ones.

Write a test program which really writes a gig file and reads it back. I have a c-source for doing this.
Let it run for several days. If it fails **ll the IBM rep. ;-) We did this tests and got interesting results...

> 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 ?

Oh, No, no, NO. Your OS and RDBMS must run without any problems.

> 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.
>

Once again: let a test program run for several days, contact me if you need the source. Do you have the latest Oracle 7.3.3 (don't know the latest versions).

Good luck,

Toni Received on Mon Jun 07 1999 - 07:43:04 CDT