V$DATABASE_BLOCK_CORRUPTION vs V$BACKUP_CORRUPTION

What is difference between V$DATABASE_BLOCK_CORRUPTION AND V$BACKUP_CORRUPTION?
both are same?

During a RMAN backup or RMAN 'backup validate' every block currently used or previously used is read into memory then written to another portion of memory. During this memory to memory write the block is checked for corruption. Therefore RMAN's BACKUP command with the VALIDATE and CHECK LOGICAL clauses allow a Database Adminstrator to quickly check for both physical and logical corruption.
The view gets populated when u do RMAN backup .While backing up the RMAN checks the blocks it backs up and populates these views (v$backup_corruption,v$copy_corruption,v$database_block_corruption. it's not abour "after the last backup" but better to say "during the last RMAN back up.
you can search the metalink for more precise information
See Note 283053.1
ref:-http://www.dbasupport.com/forums/archive/index.php/t-55234.html

Similar Messages

  • V$database_block_corruption

    hello experts
    we has logical failures on our database for which we ran following commands to validate the instance
    rman> validate check logical database;
    used dbms_repair to cehck the obejct and skip corrupted blocks
    we are still getting the same blocks in v$database_block_corruption
    FILE# BLOCK# BLOCKS CORRUPTION_CHANGE# CORRUPTIO
    52 403355 37 7.0566E+10 NOLOGGING
    67 393999 49 7.0566E+10 NOLOGGING
    86 376770 1 7.0567E+10 NOLOGGING
    92 421681 1 7.0567E+10 NOLOGGING
    92 420261 1 7.0567E+10 NOLOGGING
    Does it mean the blocks are still corrupted
    thanx

    Hi;
    Please see below thread's Aman post
    Re: V$DATABASE_BLOCK_CORRUPTION vs V$BACKUP_CORRUPTION
    Regard
    Helios

  • Oracle 10g corruption type 'unknown'

    I don't see unknown listed in the oracle docs as a corruption type.
    10.2.0.3
    DB in archivelog mode with weekly full backups
    We only keep 1 backup. No tape backups (no space. no budget for tape. Its a development environment. )
    All DBs are run from vmware. Not sure that matters
    OS: Solaris.
    checked both: v$database_block_corruption  and v$backup_corruption
    What is corruption_type = 'UNKNOWN' its not in the docs? All of my corrupt blocks in both views say 'unknown'
    This is not production. Its development. So loss of data is not a big issue. Just trying to understand the situation.
    It has been a number of years since I have had to repair block corruption. Please let me know if I am interpreting my findings correctly.
    v$backup_corruption: I have corruption in my backups
    v$database_block_corruption: corruption in my current DB
    I only have 1 backup. (no space. No budget for tape backups... this is not production. working off of VMs. not exactly high end hardware).
    Here are some additional questions:
    1. Tried running a blockrecover. Did not expect it to work since the backups appear to be corrupted too. However, I did expect RMAN to tell me that I can't fix the blocks. dd thing is I didnt get any errors. I didn't expect the blocks to be repaired since the backups are corrupted. However, I did expect some kind of message or exception. How come oracle didn't say 'hey we can't repair this'
    surprised that oracle is not telling me, I can't repair these? They dont get repaired almost certainly because the backup has corruption. Did I do something wrong or is this expected? After running this I checked v$database_block_corruption and nothing changed.
    [code]
    RMAN>     blockrecover datafile 15 block 19621,19624,19608,19611,19617,19613;
    Starting blockrecover at 07-AUG-13
    using target database control file instead of recovery catalog
    allocated channel: ORA_DISK_1
    channel ORA_DISK_1: sid=288 devtype=DISK
    starting media recovery
    media recovery complete, elapsed time: 00:00:00
    Finished blockrecover at 07-AUG-13
    [/code]
    2. I think my only other option is to use dbms_repair to flag these blocks as ignore. I know the segments involved and I can afford to ignore blocks in them. Its not the data dictionary. Is there something else I should look at?
    3. If we change the rman backup command to backup validate, will this prevent the backups from running if there is corruption and generate an error? I can write a job that can look for it and send me an email.
    4. would dbverify provide me with different data than what I got from rman?
    Anything I am missing from my approach?

    How did you determine that you've corruption in your database and in your database backups ? Any ORA- errors or messages?
    What is the output of the views ?
    2. I think my only other option is to use dbms_repair to flag these blocks as ignore. I know the segments involved and I can afford to ignore blocks in them. Its not the data dictionary. Is there something else I should look at?
    did you try to create the corrupted segments using CTAS ?
    Backup validate will only validate, by default RMAN should fail if it encounters corruption (unless specified otherwise). And I think, RMAN/dbv will provide the same output.

  • Where to find the datafile corruption ?

    I wonder, if we can find out the place from where, we can trace out about the name of datafile, which got corrupt and how to recover that file ? I can only see
    the alert.log file in that description, but really wich to hear your views.
    hare krishna
    Alok

    If MAXCORRUPT was set high enough during a backup, you can look in V$DATABASE_BLOCK_CORRUPTION for corruption entires. In addition, you could run BACKUP VALIDATE DATABASE and then check V$DATABASE_BLOCK_CORRUPTION. V$BACKUP_CORRUPTION maintains historical records of any corruption.

  • When is information stored in V$BACKUP_CORRUPTION ?

    V$BACKUP_CORRUPTION
    displays information about corrupt block ranges in datafile backups from the control file. Note that corruptions are not tolerated in the control file and archived redo log backups.
    V$DATABASE_BLOCK_CORRUPTION
    displays information about database blocks that were corrupted after the last backup.
    ^^
    When is information stored in V$BACKUP_CORRUPTION and when in V$DATABASE_BLOCK_CORRUPTION ?

    The V$DATABASE_BLOCK_CORRUPTION view indicates which blocks in a datafile were marked corrupt since the most recent BACKUP or BACKUP VALIDATE command was run via RMAN.
    V$BACKUP_CORRUPTION simply provides a historical record of entries in V$DATABASE_BLOCK_CORRUPTION.

  • V$DATABASE_BLOCK_CORRUPTION and MAXCORRUPT

    Hi,
    I am a little confused,
    from Oracle 9i doc, when using the backup command, Oracle will populates V$DATABASE_BLOCK_CORRUPTION with corrupt block ranges.
    is it necessary to set MAXCORRUPT, to allow oracle populating the V$DATABASE_BLOCK_CORRUPTION view ?
    the default limit for MAXCORRUPT is zero, and if I need to change it I would need to set MAXCORRUPT for each datafile.
    Thanks

    The documentation seems to contradict this:
    RMAN Reference
    If the sum of physical and logical corruptions detected for a file remain below
    its MAXCORRUPT setting, then the RMAN command completes and Oracle
    populates V$DATABASE_BLOCK_CORRUPTION with corrupt block ranges. If
    MAXCORRUPT is exceeded, then the command terminates without populating
    the views.
    Recovery Manager User’s Guide
    Provided the sum of physical and logical corruptions for a file remains below its
    MAXCORRUPT setting, the RMAN command completes and Oracle populates
    V$BACKUP_CORRUPTION and V$COPY_CORRUPTION with corrupt block ranges. If
    MAXCORRUPT is exceeded, the command terminates without populating the views.This would lead me to believe that MAXCORRUPT must be greater than 0 and the number of corruptions does not exceed the limit. I have not tested this so I can't confirm this.

  • Data Block Corruption

    I'm on 9i R2 Patch 7 on a Microsoft Windows Server 2003.
    How do you fix data block corruption in a Table?
    Is the some way to retrieve the data from the Table drop it then recreate and reimport the data?
    or do you have to succumb with restoring the Database from the last known good backup?

    Hey, you can do the BMR (Block Media Recovery).
    Since block corruption is to few subsets of blocks, i.e. a single table, you dont need to restore from the previous valid backup, you can simply do the following to achieve BMR.
    Connect to rman and run the following:
    run{ backup validate database};
    Once the above commend is finishes, exit from RMAN and connect to the database as / as sysdba and use the following view to know the details required for BMR.
    select * from V$backup_corruption;
    The above queries gives you file# and block# information. Once you have the information do the BMR using following command at the RMAN prompt:
    run {blockrecover datafile # block #};
    # : indicated the datafile number and block number from the above view.
    Let me know if you have any further issues.
    You can also use view V$DATABASE_BLOCK_CORRUPTION to view the file# and corrupted blocks information.
    Jaffar

  • Block corruption - cant restore from backup

    Hi,
    we have development database 11.2.0.1. There was problem with storage, and as a result there are two corrupted blocks in data files.
    SQL> select * from V$DATABASE_BLOCK_CORRUPTION;
    FILE# BLOCK# BLOCKS CORRUPTION_CHANGE# CORRUPTIO
    6 2359942 1 0 FRACTURED
    25 1855622 1 0 FRACTURED
    I have scheduled weekly full backup and daily incremental backup using EM so now I want to use rman to perform media recovery on corrupted blocks. However rman says there is no backup for affected data files (see below)
    RMAN> RECOVER CORRUPTION LIST;
    Starting recover at 03-NOV-12
    using channel ORA_DISK_1
    using channel ORA_DISK_2
    using channel ORA_DISK_3
    using channel ORA_DISK_4
    using channel ORA_DISK_5
    channel ORA_DISK_1: restoring block(s)
    channel ORA_DISK_1: specifying block(s) to restore from backup set
    restoring blocks of datafile 00006
    channel ORA_DISK_1: reading from backup piece /opt/oraBackup/rman/i2npb3o9_1_1
    channel ORA_DISK_1: piece handle=/opt/oraBackup/rman/i2npb3o9_1_1 tag=BACKUP_FULL_110212103009
    channel ORA_DISK_1: restored block(s) from backup piece 1
    channel ORA_DISK_1: block restore complete, elapsed time: 00:42:35
    channel ORA_DISK_1: restoring block(s)
    channel ORA_DISK_1: specifying block(s) to restore from backup set
    restoring blocks of datafile 00025
    channel ORA_DISK_1: reading from backup piece /opt/oraBackup/rman/i9npbd5e_1_1
    channel ORA_DISK_1: piece handle=/opt/oraBackup/rman/i9npbd5e_1_1 tag=BACKUP_FULL_110212103009
    channel ORA_DISK_1: restored block(s) from backup piece 1
    channel ORA_DISK_1: block restore complete, elapsed time: 00:16:35
    failover to previous backup
    RMAN-00571: ===========================================================
    RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
    RMAN-00571: ===========================================================
    RMAN-03002: failure of recover command at 11/03/2012 11:59:29
    RMAN-06026: some targets not found - aborting restore
    RMAN-06023: no backup or copy of datafile 25 found to restore
    RMAN-06023: no backup or copy of datafile 6 found to restore
    I dont understand this, because the backups are performed weekly and daily and all files are at their proper location. When I check the EM backup reports, I see COMPLETED for every weekly and daily backup.
    Anyone please could suggest how to repair the blocks from backups ?

    Hi people, I am back to this issue. I have found this in the database
    SQL> select * from v$backup_corruption;
         RECID      STAMP  SET_STAMP  SET_COUNT     PIECE#      FILE#     BLOCK#     BLOCKS CORRUPTION_CHANGE# MAR CORRUPTIO
             1  796949262  796948233       9293          1          6    2359942          1                  0 NO  CORRUPT
             2  796953328  796949174       9300          1         25    1855622          1                  0 NO  CORRUPT
             3  797035604  797034635       9318          1          6    2359942          1                  0 NO  CORRUPT
             4  797039692  797035556       9325          1         25    1855622          1                  0 NO  CORRUPT
             5  797134390  797121030       9343          1          6    2359942          1                  0 NO  CORRUPT
             6  797137228  797134397       9368          1         25    1855622          1                  0 NO  CORRUPT
             7  797739951  797725854       9590          1          6    2359942          1                  0 NO  CORRUPT
             8  797744507  797739957       9597          1         25    1855622          1                  0 NO  CORRUPT
             9  798340269  798330633       9794          1          6    2359942          1                  0 NO  CORRUPT
            10  798343497  798340270       9801          1         25    1855622          1                  0 NO  CORRUPTSo the backup contains corrupted blocks. Right ? Older backups are already gone because of retention policy.
    I have set up the backup using Enterprise Manager - Schedule Backup.
    What I need to know is how to avoid taking backup with corrupted blocks in future. I need such backup to fail.
    Thank you for advices and regards.

  • Corrupted blocks

    Corrupted blocks are shown after runnıng dbv
    but I cant see them from the
    V$backup_corruption
    v$database_block_corruption;
    why?

    Was dbv supposed to mark the block corrupt somewhere?
    The V$DATABASE_BLOCK_CORRUPTION view indicates which blocks in a datafile were marked corrupt since the most recent BACKUP or BACKUP VALIDATE command was run.

  • Block corruption recovery!!

    Hi. all.
    I am testing a recovery in the event of block corruption.
    As far as I know, the solution to block corruption is as followings:
    1. BlockRecover command (RMAN)
    2. drop the table and import from backup dump file
    3. DBMS_REPAIR package
    4. complete recovery from online full backup
    My question is whether No. 4 is possible or not.
    step 1 : bring the datafile offline
    step 2 : restore the datafile from the last backup(online backup)
    step 3: recover the datafile, applying archive logs and online redo logs
    step 4 : bring the datafile online
    The above steps are enough for block corruption recovery?
    I need to make a document about block corruption issue, but
    I have no experience of recovering block corruption.
    Thanks in advance.
    Best Regards.

    If few blocks are corrupted, it is advisable to run the BMR (block media recover, staring with 9i). This option provides the availability of other data present in datafile.
    Option 4 is okay when most of the data block in a datafile got corrupted.
    To know how many blocks got corrupted in the datafile, run the following:
    SELECT * FROM V$DATABASE_BLOCK_CORRUPTION;
    SELECT * FROM V$COPY_CORRUPTION;
    SELECT * FROM V$BACKUP_CORRUPTION;
    You need to look into corrution_type and blocks columns in the v$database_block_corruption view as it gives the reason for block corruption and number of blocks are corrupted in a datafile.
    Jaffar

  • Error in Database backup using RMAN.

    Hi
    While taking full online backup using RMAN i got the following error.
    ORA-19566: exceeded limit of 0 corrupt blocks for file /oracle/DEV/sapdata2/dev640_6/dev640.data6
    Please help me how to resolve this issue.

    Hi,
    Please perform DBverify Job and Also analyze the alert<SID>.log file for your Database to get more information about such logical or physical corruption.  You may require Block level recovery for the complained DB Files. Please refer this useful document " [Early Detection and Correction of Data Block Corruptions Using RMAN |http://www.ioug.org/client_files/members/select_pdf/04q4/RMAN.pdf]" and share the same with your Oracle DBA.
    You can execute the following commands to get information about corrupted block(s), if its there.
    select * from v$backup_corruption;
    select * from v$database_block_corruption;
    Regads,
    Bhavik G. Shroff

  • Corrupted control file?

    Hi there,
    I have an Oracle 10.2.0.3 DB running on Solaris 10 update 5, SPARC 64-bit.
    I recently noticed that there are a number of files in my backupsets that have been flagged as corrupt:
    <pre>
    SQL> select recid, stamp, set_count, file#, marked_corrupt, media_corrupt, logically_corrupt
    2 from v$backup_datafile
    3 where checkpoint_change# >= 2215146265248
    4 and (marked_corrupt > 0 or media_corrupt > 0 or logically_corrupt > 0);
    </pre>
    <pre>
    RECID STAMP SET_COUNT FILE# MARKED_CORRUPT MEDIA_CORRUPT LOGICALLY_CORRUPT
    99977 746035916 15992 0 2011 317 1
    99978 746132372 15998 0 2011 318 0
    99979 746153962 15999 0 2011 319 0
    </pre>
    File#=0 means that this is corruption is on the control file.
    I checked a couple other views for more information, but I can't find anything about this:
    <pre>
    SQL> select * from v$backup_corruption;
    no rows selected
    SQL> select * from v$database_block_corruption;
    no rows selected
    </pre>
    Can anyone please explain what this information really means and how bad of a situation this is? What methods are available to resolve this issue?

    Thanks for answering so quickly.
    There are 3 copies of the controlfile available. They all have the same size & timestamp:
    <pre>
    -rw-r----- 1 oracle oinstall 38453248 Mar 20 14:17 control01.ctl
    -rw-r----- 1 oracle oinstall 38453248 Mar 20 14:17 control02.ctl
    -rw-r----- 1 oracle oinstall 38453248 Mar 20 14:17 control03.ctl
    </pre>
    DB is operating normally. We did have problems with our RMAN backups (incremental level 0) over this past weekend to our external tape system, which led me down this path.
    There are no errors in the alert log.
    I am not completely convinced my control files are corrupted though. What would be an easy way to check for corruption without taking DB down?

  • Corruption & Sysman

    Hi all,
    here is my situation.
    This instance is our Production Instance.
    The setup is:
    10.2.0.3 on Redhat
    After analyzing with rman - Backup validate check logical database; - I got the following result:
    select *
    from v$database_block_corruption
    FILE# BLOCK# BLOCKS CORRUPTION_CHANGE# CORRUPTION_TYPE
    3 23704 1 124547349 LOGICAL
    select *
    from v$backup_corruption
    RECID STAMP SET_STAMP SET_COUNT PIECE# FILE# BLOCK# BLOCKS CORRUPTION_CHANGE# MARKED_CORRUPT CORRUPTION_TYPE
    1 636798080 636796682 169 1 3 23704 1 124547349 YES LOGICAL
    The next step:
    SELECT tablespace_name, relative_fno,
    segment_type, owner, segment_name, partition_name
    FROM dba_extents
    WHERE file_id = 3
    AND 23704 between block_id and block_id + blocks -1;
    TABLESPACE_NAME RELATIVE_FNO SEGMENT_TYPE OWNER SEGMENT_NAME PARTITION_NAME
    SYSAUX 3 TABLE SYSMAN MGMT_CURRENT_AVAILABILITY
    So it seems my corruption is in a table named MGMT_CURRENT_AVAILABILITY under the sysman schema.
    That makes sense since I actually cannot schedule anything with EM.
    I cannot select * that table nor export it. I always got an Invalid ROWID error.
    What is the safest way to correct my problem?
    emca -deconfig dbcontrol db -repos drop
    then
    emca -config dbcontrol db -repos recreate
    Is it safe?
    TIA

    Hi, the options will can be:
    1.- Use the BLOCKRECOVER for try recover the bad data blocks, please see the next link for get more information about how use this command.
    http://download.oracle.com/docs/cd/B19306_01/backup.102/b14194/rcmsynta010.htm#sthref213
    2.- Recreate the EM schema with.
    emca -deconfig dbcontrol db -repos drop
    then
    emca -config dbcontrol db -repos recreate
    Please let me know if you need anything else.
    Regards.

  • Urgent- block corruption on standby and recovery thru physical copy file

    Hi all,
    We have a ORacle 9.2.0.6 DB and we have manula physical standby DB.
    We got a block corruption on standby and I got to know thru metalink that we have to copy the data file from primary to standby but
    my question is when we copy the datafile from primary to standby, will i be able to do the same because I think the SCN may varies ,as when i down the standby to copy the datafile ,oracle server wrtie a SCN to the control file of standby and when i will open it it will throw an error....
    Please suggest me....

    we are having n numbers od block corruption so what should be the exact value in
    alter database recover automatic standby database allow *1* corruptionpls suggeest me
    select * from v$backup_corruption;
    RECID     STAMP     SET_STAMP     SET_COUNT     PIECE#     FILE#     BLOCK#     BLOCKS     CORRUPTION_CHANGE#     MARKED_CORRUPT     CORRUPTION_TYPE
    1     679059926     679058677     54     1     3     299997     12     1790569359     NO     LOGICAL
    2     679059926     679058677     54     1     3     300010     15     1790569374     NO     LOGICAL
    3     679059926     679058677     54     1     3     300026     15     1790569389     NO     LOGICAL
    4     679059926     679058677     54     1     3     300042     7     1790569404     NO     LOGICAL
    5     679059926     679058677     54     1     3     300433     8     1790569404     NO     LOGICAL
    6     679059926     679058677     54     1     3     300442     15     1790569419     NO     LOGICAL
    7     679059926     679058677     54     1     3     300458     15     1790569434     NO     LOGICAL
    8     679059926     679058677     54     1     3     300690     15     1790569450     NO     LOGICAL
    9     679059926     679058677     54     1     3     300930     7     1790569465     NO     LOGICAL
    10     679059926     679058677     54     1     3     2427217     64     1545959567     NO     LOGICAL
    11     679059926     679058677     54     1     3     3078291     126     1790569473     NO     LOGICAL
    12     679059926     679058677     54     1     3     3236929     8     1790569465     NO     LOGICAL
    13     679059926     679058677     54     1     3     3236941     12     1790464761     NO     LOGICAL
    14     679059926     679058677     54     1     3     3236954     15     1790464776     NO     LOGICAL
    15     679059926     679058677     54     1     3     3236970     15     1790464792     NO     LOGICAL
    16     679059926     679058677     54     1     3     3236986     15     1790464807     NO     LOGICAL
    17     679059926     679058677     54     1     3     3237002     7     1790464822     NO     LOGICAL
    18     679059926     679058677     54     1     3     3242641     8     1790464822     NO     LOGICAL
    19     679059926     679058677     54     1     3     3242650     15     1790464837     NO     LOGICAL
    20     679059926     679058677     54     1     3     3242666     15     1790464852     NO     LOGICAL
    21     679059926     679058677     54     1     3     3242682     15     1790464867     NO     LOGICAL
    22     679059926     679058677     54     1     3     3242771     40     1790464875     NO     LOGICAL
    23     679059926     679058677     54     1     3     3242899     126     1790569482     NO     LOGICAL
    24     679059926     679058677     54     1     3     3243027     126     1790569491     NO     LOGICAL
    25     679059926     679058677     54     1     3     3243155     126     1790569500     NO     LOGICAL
    26     679059926     679058677     54     1     3     3243283     126     1790569509     NO     LOGICAL
    27     679059926     679058677     54     1     3     3243411     126     1790569518     NO     LOGICAL
    28     679059926     679058677     54     1     3     3243539     126     1790569527     NO     LOGICAL
    29     679059926     679058677     54     1     3     3243667     126     1790569536     NO     LOGICAL
    30     679059926     679058677     54     1     3     3243795     126     1790569545     NO     LOGICAL
    31     679059926     679058677     54     1     3     3243923     126     1790569554     NO     LOGICAL
    32     679059926     679058677     54     1     3     3244051     126     1790569564     NO     LOGICAL
    33     679059926     679058677     54     1     3     3244179     126     1790569573     NO     LOGICAL
    34     679059926     679058677     54     1     3     3244307     126     1790569582     NO     LOGICAL
    35     679059926     679058677     54     1     3     3244435     126     1790569591     NO     LOGICAL
    36     679059926     679058677     54     1     3     3244563     126     1790569600     NO     LOGICAL
    37     679059926     679058677     54     1     3     3244691     126     1790569609     NO     LOGICAL
    38     679059926     679058677     54     1     3     3244819     126     1790569618     NO     LOGICAL
    39     679059926     679058677     54     1     3     3244947     126     1790569627     NO     LOGICAL
    40     679059926     679058677     54     1     3     3245075     126     1790569637     NO     LOGICAL
    41     679059926     679058677     54     1     3     3245203     126     1790569646     NO     LOGICAL
    42     679059926     679058677     54     1     3     3245331     126     1790569655     NO     LOGICAL
    43     679059926     679058677     54     1     3     3245459     126     1790569664     NO     LOGICAL
    44     679059926     679058677     54     1     3     3245587     126     1790569673     NO     LOGICAL
    45     679059926     679058677     54     1     3     3245715     126     1790569683     NO     LOGICAL
    46     679059926     679058677     54     1     3     3245843     126     1790569692     NO     LOGICAL
    47     679059926     679058677     54     1     3     3245971     126     1790569701     NO     LOGICAL
    48     679059926     679058677     54     1     3     3246099     126     1790569710     NO     LOGICAL
    49     679059926     679058677     54     1     3     3246227     126     1790569719     NO     LOGICAL
    50     679059926     679058677     54     1     3     3246355     126     1790569728     NO     LOGICAL
    51     679059926     679058677     54     1     3     3246483     126     1790569737     NO     LOGICAL
    52     679059926     679058677     54     1     3     3246611     126     1790569746     NO     LOGICAL
    53     679059926     679058677     54     1     3     3246739     126     1790569755     NO     LOGICAL
    54     679059926     679058677     54     1     3     3246867     126     1790569764     NO     LOGICAL
    55     679059926     679058677     54     1     3     3246995     126     1790569773     NO     LOGICAL
    56     679059926     679058677     54     1     3     3247123     126     1790569782     NO     LOGICAL
    57     679059926     679058677     54     1     3     3247251     126     1790569791     NO     LOGICAL
    58     679059926     679058677     54     1     3     3247379     126     1790569801     NO     LOGICAL
    59     679059926     679058677     54     1     3     3247507     126     1790569811     NO     LOGICAL
    60     679059926     679058677     54     1     3     3247635     126     1790569820     NO     LOGICAL
    61     679059926     679058677     54     1     3     3247763     126     1790569829     NO     LOGICAL
    62     679059926     679058677     54     1     3     3247891     126     1790569838     NO     LOGICAL
    63     679059926     679058677     54     1     3     3248019     126     1790569847     NO     LOGICAL
    64     679059926     679058677     54     1     3     3248147     126     1790569856     NO     LOGICAL
    65     679059926     679058677     54     1     3     3248275     126     1790569865     NO     LOGICAL
    66     679059926     679058677     54     1     3     3248403     126     1790569874     NO     LOGICAL
    67     679059926     679058677     54     1     3     3248531     126     1790569883     NO     LOGICAL
    68     679059926     679058677     54     1     3     3248659     126     1790569892     NO     LOGICAL
    69     679059926     679058677     54     1     3     3248787     126     1790569901     NO     LOGICAL
    70     679059926     679058677     54     1     3     3248915     126     1790569910     NO     LOGICAL
    71     679059926     679058677     54     1     3     3249043     126     1790569920     NO     LOGICAL
    72     679059926     679058677     54     1     3     3249171     126     1790569929     NO     LOGICAL
    73     679059926     679058677     54     1     3     3249299     126     1790569938     NO     LOGICAL
    74     679059926     679058677     54     1     3     3249427     126     1790569947     NO     LOGICAL
    75     679059926     679058677     54     1     3     3249555     126     1790569956     NO     LOGICAL
    76     679059926     679058677     54     1     3     3249683     126     1790569965     NO     LOGICAL
    77     679059926     679058677     54     1     3     3249811     126     1790569974     NO     LOGICAL
    78     679059926     679058677     54     1     3     3249939     126     1790569984     NO     LOGICAL
    79     679059926     679058677     54     1     3     3250067     126     1790569993     NO     LOGICAL
    80     679059926     679058677     54     1     3     3250195     126     1790570002     NO     LOGICAL
    81     679059926     679058677     54     1     3     3250323     126     1790570011     NO     LOGICAL
    82     679059926     679058677     54     1     3     3250451     126     1790570020     NO     LOGICAL
    83     679059926     679058677     54     1     3     3250579     126     1790570029     NO     LOGICAL
    84     679059926     679058677     54     1     3     3250706     127     1790570039     NO     LOGICAL
    85     679059926     679058677     54     1     3     3250837     1020     1790570048     NO     LOGICAL
    86     679059926     679058677     54     1     3     3251861     1020     1790570057     NO     LOGICAL
    87     679059926     679058677     54     1     3     3252885     1020     1790570067     NO     LOGICAL
    88     679059926     679058677     54     1     3     3253909     1020     1790570076     NO     LOGICAL
    89     679059926     679058677     54     1     3     3254933     1020     1790570086     NO     LOGICAL
    90     679059926     679058677     54     1     3     3255957     1020     1790570095     NO     LOGICAL
    91     679059926     679058677     54     1     3     3256981     1020     1790570104     NO     LOGICAL
    92     679059926     679058677     54     1     3     3258005     1020     1790570114     NO     LOGICAL
    93     679059926     679058677     54     1     3     3259029     1020     1790570123     NO     LOGICAL
    94     679059926     679058677     54     1     3     3260053     1020     1790570133     NO     LOGICAL
    95     679059926     679058677     54     1     3     3261077     486     1790570142     NO     LOGICAL     NO     LOGICAL
    SQL> select * from v$database_block_corruption;
         FILE#     BLOCK#     BLOCKS CORRUPTION_CHANGE# CORRUPTIO
             3     299997         12         1790569359 LOGICAL
             3     300010         15         1790569374 LOGICAL
             3     300026         15         1790569389 LOGICAL
             3     300042          7         1790569404 LOGICAL
             3     300433          8         1790569404 LOGICAL
             3     300442         15         1790569419 LOGICAL
             3     300458         15         1790569434 LOGICAL
             3     300690         15         1790569450 LOGICAL
             3     300930          7         1790569465 LOGICAL
             3    2427217         64         1545959567 LOGICAL
             3    3078291        126         1790569473 LOGICAL
         FILE#     BLOCK#     BLOCKS CORRUPTION_CHANGE# CORRUPTIO
             3    3236929          8         1790569465 LOGICAL
             3    3236941         12         1790464761 LOGICAL
             3    3236954         15         1790464776 LOGICAL
             3    3236970         15         1790464792 LOGICAL
             3    3236986         15         1790464807 LOGICAL
             3    3237002          7         1790464822 LOGICAL
             3    3242641          8         1790464822 LOGICAL
             3    3242650         15         1790464837 LOGICAL
             3    3242666         15         1790464852 LOGICAL
             3    3242682         15         1790464867 LOGICAL
             3    3242771         40         1790464875 LOGICAL
         FILE#     BLOCK#     BLOCKS CORRUPTION_CHANGE# CORRUPTIO
             3    3242899        126         1790569482 LOGICAL
             3    3243027        126         1790569491 LOGICAL
             3    3243155        126         1790569500 LOGICAL
             3    3243283        126         1790569509 LOGICAL
             3    3243411        126         1790569518 LOGICAL
             3    3243539        126         1790569527 LOGICAL
             3    3243667        126         1790569536 LOGICAL
             3    3243795        126         1790569545 LOGICAL
             3    3243923        126         1790569554 LOGICAL
             3    3244051        126         1790569564 LOGICAL
             3    3244179        126         1790569573 LOGICAL
         FILE#     BLOCK#     BLOCKS CORRUPTION_CHANGE# CORRUPTIO
             3    3244307        126         1790569582 LOGICAL
             3    3244435        126         1790569591 LOGICAL
             3    3244563        126         1790569600 LOGICAL
             3    3244691        126         1790569609 LOGICAL
             3    3244819        126         1790569618 LOGICAL
             3    3244947        126         1790569627 LOGICAL
             3    3245075        126         1790569637 LOGICAL
             3    3245203        126         1790569646 LOGICAL
             3    3245331        126         1790569655 LOGICAL
             3    3245459        126         1790569664 LOGICAL
             3    3245587        126         1790569673 LOGICAL
         FILE#     BLOCK#     BLOCKS CORRUPTION_CHANGE# CORRUPTIO
             3    3245715        126         1790569683 LOGICAL
             3    3245843        126         1790569692 LOGICAL
             3    3245971        126         1790569701 LOGICAL
             3    3246099        126         1790569710 LOGICAL
             3    3246227        126         1790569719 LOGICAL
             3    3246355        126         1790569728 LOGICAL
             3    3246483        126         1790569737 LOGICAL
             3    3246611        126         1790569746 LOGICAL
             3    3246739        126         1790569755 LOGICAL
             3    3246867        126         1790569764 LOGICAL
             3    3246995        126         1790569773 LOGICAL
         FILE#     BLOCK#     BLOCKS CORRUPTION_CHANGE# CORRUPTIO
             3    3247123        126         1790569782 LOGICAL
             3    3247251        126         1790569791 LOGICAL
             3    3247379        126         1790569801 LOGICAL
             3    3247507        126         1790569811 LOGICAL
             3    3247635        126         1790569820 LOGICAL
             3    3247763        126         1790569829 LOGICAL
             3    3247891        126         1790569838 LOGICAL
             3    3248019        126         1790569847 LOGICAL
             3    3248147        126         1790569856 LOGICAL
             3    3248275        126         1790569865 LOGICAL
             3    3248403        126         1790569874 LOGICAL
         FILE#     BLOCK#     BLOCKS CORRUPTION_CHANGE# CORRUPTIO
             3    3248531        126         1790569883 LOGICAL
             3    3248659        126         1790569892 LOGICAL
             3    3248787        126         1790569901 LOGICAL
             3    3248915        126         1790569910 LOGICAL
             3    3249043        126         1790569920 LOGICAL
             3    3249171        126         1790569929 LOGICAL
             3    3249299        126         1790569938 LOGICAL
             3    3249427        126         1790569947 LOGICAL
             3    3249555        126         1790569956 LOGICAL
             3    3249683        126         1790569965 LOGICAL
             3    3249811        126         1790569974 LOGICAL
         FILE#     BLOCK#     BLOCKS CORRUPTION_CHANGE# CORRUPTIO
             3    3249939        126         1790569984 LOGICAL
             3    3250067        126         1790569993 LOGICAL
             3    3250195        126         1790570002 LOGICAL
             3    3250323        126         1790570011 LOGICAL
             3    3250451        126         1790570020 LOGICAL
             3    3250579        126         1790570029 LOGICAL
             3    3250706        127         1790570039 LOGICAL
             3    3250837       1020         1790570048 LOGICAL
             3    3251861       1020         1790570057 LOGICAL
             3    3252885       1020         1790570067 LOGICAL
             3    3253909       1020         1790570076 LOGICAL
         FILE#     BLOCK#     BLOCKS CORRUPTION_CHANGE# CORRUPTIO
             3    3254933       1020         1790570086 LOGICAL
             3    3255957       1020         1790570095 LOGICAL
             3    3256981       1020         1790570104 LOGICAL
             3    3258005       1020         1790570114 LOGICAL
             3    3259029       1020         1790570123 LOGICAL
             3    3260053       1020         1790570133 LOGICAL
             3    3261077        486         1790570142 LOGICAL
    95 rows selected.
    SQL>

  • Frequent Block Corruption alert .........

    We are getting more frequent Block corruption alert from our production RAC (2 node) db.
    if we use dbv utility to check block corruption, everything looks normal and if we check following dictionary views, we could not find any details .
    GV$BACKUP_CORRUPTION, GV$COPY_CORRUPTION, GV$DATABASE_BLOCK_CORRUPTION
    So do we have block corruption ? what we can do to avoid getting such alerts?

    Hi,
    >>We are getting more frequent Block corruption alert from our production RAC (2 node) db.
    What exactly error are you getting from alert log file?
    >>if we use dbv utility to check block corruption, everything looks normal and if we check following dictionary views, we could not find any details
    In fact, these views above displays information about corruptions in datafile and/or datafile copy backups from the control file. I think this is the wrong place to look at. In addition, there are many possible causes of a block corruption including bad IO, hardware / firmware, OS problems, Oracle problems ... Are you able to determine which database objects have affected by this problem? Have you tried take a look at some trace files?
    Cheers
    Legatti

Maybe you are looking for