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

    ---