Djordje,
Sorry, but I have to disagree with you. If accessing
the same block inconsistently gives a data block
corruption error this screams hardware or OS problems.
You didn't list the error, but I'm assuming it's an
ORA-1578 "data block corrupted". This indicates that
either the info in the header of the block isn't the
right format or it doesn't match the checksum info in
the footer of the block. From the symptoms you're
describing, the block isn't corrupt on disk, but is
somehow getting corrupted while being read into
memory.
> and that oracle have
> problem with reading cached
> blocks that are being inserted/updated at the same
> time as retrieved.
No offense, but if this were the case it would render
Oracle virtually unusable.
Again, I'm very skeptical that this is an Oracle bug.
I would check out everything on this server, not just
the EMC disks. If you can, try moving this db to
another server. If it's truly a bug you should
continue getting the corruption errors.
HTH,
- Anita
- djordjej <djordjej_at_attcanada.ca> wrote:
> Hi Anita,
>
> Thanks for the responce. I find the idea with
> setting the event in order
> not to access a certain block very interesting.
> Talking of the structure of
> the orav\cle block in Velpuri's book on backup there
> is an analysis of the
> oracle block structure. Unfortunately I never had
> time to play with it, but
> I hope I will.
>
> Just to update you all of my new today's findings.
>
> 1. Every time I was running one certain statement
> that does a full table
> scan I was a getting e new "corrupted" block number,
> and thos block numbers
> kept increasing.
> 2. I had a list of reported "corrupted" blocks. I
> was able later (say 10+
> minutes after the corrupt report) to retreive data
> from the block (using the
> rowid search) without a problem.
> 3. Late last night I ran twice analyze table ...
> (though without cascade,
> which as far as I understand just checkes the
> indexes atop) and both times
> without an error.
>
> Taking all this in consideration, my current theory
> is that we have hit an
> oracle bug (feature ;-) ) and that oracle have
> problem with reading cached
> blocks that are being inserted/updated at the same
> time as retrieved. One
> of the reasons for that theory is that I feel that
> table of this size (I
> have not mentioned it has 33M rows) is not that
> usual for 7.2.2.4.
>
> The disk is EMC which have a bunch of tests that are
> running all the time,
> and it has not detected any problem so far.
>
> The OS version is OK.
>
> As the answer to another response to my question is
> that dbv unfortunatelly
> does not exits on 7.2.2.4.
>
> Any new ideas.
>
> Djordje
>
> -----Original Message-----
> From: A. Bardeen <abardeen1_at_yahoo.com>
> To: ORACLE-L_at_fatcity.com <ORACLE-L_at_fatcity.com>;
> djordjej_at_netcom.ca
> <djordjej_at_netcom.ca>
> Date: Friday, June 02, 2000 9:15 AM
> Subject: Re: Datablock corruption
>
>
> >Djordje,
> >
> >Color me suspicious, but I doubt that Oracle is
> >wrongly formatting the blocks. I'm more inclined
> to
> >believe that it's a hardware or OS problem.
> Certainly
> >if you run an ANALYZE TABLE VALIDATE STRUCTURE
> CASCADE
> >on the table multiple times and it returns
> different
> >corrupt blocks, that's a definite sign of hardware
> or
> >OS problems, although the same block being returned
> >doesn't rule out hardware or OS problems.
> >
> >Unfortunately there's no way that I know of to
> access
> >the data in a corrupt block. In the case of such a
> >large table or tables that contain raw/long raw
> data
> >where you can't use SQL to select around the
> corrupt
> >blocks there are events which can be set which will
> >mark the blocks as corrupt and then allow Oracle to
> >skip the corrupt blocks so that the table, sans the
> >corrupted blocks, can be exported.
> >
> >This shouldn't be undertaken without the advice of
> >Oracle support or someone experienced with using
> these
> >events as blocks with minor corruption
> (inconsistency
> >between the calculations for space used and space
> free
> >in the block, for example) to be marked as corrupt,
> >thereby making the data in that block inaccessible.
> >
> >As a last resort, depending on the type of
> corruption
> >(inconsistency in the block header, for example),
> >Oracle Support might be able to "patch" the corrupt
> >blocks. I would expect there to be a charge for
> this.
> > DUL is not an option here as it is unable to read
> >corrupt blocks.
> >
> >> BTW the version is fresh new 7.2.2.4.
> > bit of an oxymoron considering how many years 7.2
> >has been desupported ;)
> >
> >Speaking of which, are you running on an OS version
> >certified for 7.2.2?
> >
> >HTH,
> >
> >-- Anita
> >
> >
> >--- djordjej <djordjej_at_netcom.ca> wrote:
> >> Hi,
> >>
> >> Any experiencies/advices with block corruptions
> >> (other than the ones
> >> proposed by oracle - analyze, exclude block using
> >> rowid, see the data using
> >> indexes).
> >>
> >> It seems to me that oracle has wrongly formated
> the
> >> extent and that most of
> >> the newly filled blocks are having corruptions.
> At
> >> the same time, of
> >> course, the table is pretty huge (~ 6G), mission
> >> critical and heavilly used.
> >> Downtime to do all the stuff properly would be
> >> killing.
> >>
> >> BTW the version is fresh new 7.2.2.4.
> >>
> >> Any help would be appreciated.
> >>
> >> Djordje
> >>
> >>
> >> --
> >> Author: djordjej
> >> INET: djordjej_at_netcom.ca
> >>
> >> Fat City Network Services -- (858) 538-5051
> FAX:
> >> (858) 538-5051
> >> San Diego, California -- Public Internet
> >> access / Mailing Lists
> >>
>
>--------------------------------------------------------------------
> >> To REMOVE yourself from this mailing list, send
> an
> >> E-Mail message
> >> to: ListGuru_at_fatcity.com (note EXACT spelling of
> >> 'ListGuru') and in
> >> the message BODY, include a line containing:
> UNSUB
> >> ORACLE-L
> >> (or the name of mailing list you want to be
> removed
> >> from). You may
> >> also send the HELP command for other information
> >> (like subscribing).
> >
> >
> >__________________________________________________
> >Do You Yahoo!?
Received on Fri Jun 02 2000 - 22:36:12 CDT
