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

Search Discussions

  • A. Bardeen at Jun 2, 2000 at 1:15 pm
    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 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).
  • A. Bardeen at Jun 3, 2000 at 3:36 am
    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 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
    To: ORACLE-L_at_fatcity.com;
    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 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!?

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouporacle-l @
categoriesoracle
postedJun 2, '00 at 6:10a
activeJun 3, '00 at 3:36a
posts3
users2
websiteoracle.com

2 users in discussion

A. Bardeen: 2 posts Djordjej: 1 post

People

Translate

site design / logo © 2022 Grokbase