Re: avoiding corrupted block (ora-01578)

Hi Toni,

    Thank for your responses, these are the answers for you. ( man ! you have more "?" than I do, just joking ...I am answering then so that everybody can have a better feel of my environment).

    "perfect climatic" condition, I am not quite sure what it means, I guss you are refering to temperature, humility, air flow etc. Yes, we do have a "computer room" equipped with normal UPS, air conditioner, fire precaution etc etc.

    We don't power down nor os shutdown the server for too long ( 2 hour max ).

    There is a parameter in init.ora, we will turn it on and see what is the impact.

    We don't see any related msg in "errpt".     alert.log don't show any thing, is the /<SID>/udump/ora_<pid>.ora that show us the ora-01578 and ora-01* error msg.

    Give me a copy of your C source to read/write gig file. Thank you !

    Is there something we can do at Start of day to scan for bad blocks before we allow user to use it ? We can estimate the daily usage size.

Regards
Nathan Phan

In article <070619991443042465%dischner_at_klch.med.uni-muenchen.de>,   Anton Dischner <dischner_at_klch.med.uni-muenchen.de> wrote:
> 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
>

Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't. Received on Mon Jun 07 1999 - 22:06:31 CDT