| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Usenet -> c.d.o.server -> Re: avoiding corrupted block (ora-01578)
In this configuration, you might run into bugs 874948, base bug 883260.
I asked Oracle support to publish these so we can track using MetaLink
In short, AIX 4.3.0+ can develop bad blocks if AIX“s native async I/O is
being used. This is NOT a problem with AIX 4.3.0 or lower.
- workaround is to disable asynchronous o/i by modifying the init.ora file: --- disk_asynch_io = false --- dbwr_io_slaves = <number of slaves>Whenever disk_asynch_io is set to false, it is stronly recommended to do the same for tape_asynch_io.
Nathan Phan wrote:
> 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 Wed Jun 09 1999 - 05:10:16 CDT
 |
 |