BR0398E DBVERIFY detected corrupted blocks in TS SAPSR3

Hi!
After DBVerify I get the following error:
BR0398E DBVERIFY detected corrupted blocks in /oracle/<sid>/sapdata4/sr3_8/sr3.data8
Furthermore I get the following warning/information:
Completely zero block found during dbv:
Page 286685 is marked corrupt
Question:
1) Does it mean that my database is corrupt and should be recovered from a valid backup?
2) What is the approach to handle here and to solve the error?
Enclosed the output of the following SQL commandos:
> select dbms_utility.data_block_address_block(1522735858) from dual;
DBMS_UTILITY.DATA_BLOCK_ADDRESS_BLOCK(1522735858)
                                           203506
> select dbms_utility.data_block_address_file(1522735858) from dual;
DBMS_UTILITY.DATA_BLOCK_ADDRESS_FILE(1522735858)
                                             363
> select file#, rfile# from v$datafile where name = '/oracle/<sid>/sapdata4/sr3_8/sr3.data8';
     FILE#     RFILE#
        11         11
> select segment_name, partition_name, segment_type, block_id, blocks   from dba_extents   where (203506 between block_id and (block_id + blocks - 1))   and file_id = 363 and rownum<2;
no rows selected
Thank you very much!

Hi!
Some additional information
SQL> SELECT dbms_utility.data_block_address_block(1522735858) "BLOCK", dbms_utility.data_block_address_file(1522735858) "FILE" FROM dual;
     BLOCK       FILE
    203506        363
After this I executed alter system dump commando:
> alter system dump datafile 363 block 203506;
When I open the generated dump file I can see:
Error: alter system dump datafile/tempfile: invalid input file # 363
SQL>  select owner, segment_name, partition_name, segment_type, block_id, blocks
  2  from dba_extents  
  3 where (525 between
  +4  block_id and (block_id + blocks - 1))+
  5  and file_id = 4
  6  and rownum < 2;
OWNER SEGMENT_NAME PARTITION_NAME   SEGMENT_TYPE         BLOCK_ID     BLOCKS
SAPSR3                    DD08T~0                   INDEX                           521        128
Question
Should I run the following SQL commando or how can I solve my problem?
ALTER INDEX DD08T~0 REBUILD ONLINE;

Similar Messages

  • Block Corruption (BR0398E DBVERIFY detected corrupted blocks in /oracle/TS2

    Hello Gurus
    I am facing Data Block corruption error for single datafile....
    BR0278W Command output of '/oracle/TS2/102_64/bin/dbv file=/oracle/TS2/sapdata3/ts2_73/ts2.data73 blocksize=8192':
    DBVERIFY: Release 10.2.0.2.0 - Production on Thu Jul 17 23:31:25 2008
    Copyright (c) 1982, 2005, Oracle.  All rights reserved.
    DBVERIFY - Verification starting : FILE = /oracle/TS2/sapdata3/ts2_73/ts2.data73
    Block Checking: DBA = 528925394, Block Type = KTB-managed data block
    row 4: key out of order
         end index block validation
    Page 443090 failed with check code 6401
    DBVERIFY - Verification complete
    Total Pages Examined         : 1280000
    Total Pages Processed (Data) : 248379
    Total Pages Failing   (Data) : 0
    Total Pages Processed (Index): 180541
    Total Pages Failing   (Index): 1
    Total Pages Processed (Other): 13272
    Total Pages Processed (Seg)  : 0
    Total Pages Failing   (Seg)  : 0
    Total Pages Empty            : 837808
    Total Pages Marked Corrupt   : 0
    Total Pages Influx           : 0
    Highest block SCN            : 65006255 (0.65006255)
    BR0398E DBVERIFY detected corrupted blocks in /oracle/TS2/sapdata3/ts2_73/ts2.data73
    appriciated help please..
    Regards
    Giridhar.

    Dump file /oracle/TS2/saptrace/usertrace/ts2_ora_23103.trc
    Oracle Database 10g Enterprise Edition Release 10.2.0.2.0 - 64bit Production
    With the Partitioning and Data Mining options
    ORACLE_HOME = /oracle/TS2/102_64
    System name:    SunOS
    Node name:      sassad25
    Release:        5.10
    Version:        Generic_120011-14
    Machine:        sun4u
    Instance name: TS2
    Redo thread mounted by this instance: 1
    Oracle process number: 53
    Unix process pid: 23103, image: oracle@sassad25 (TNS V1-V3)
    2008-07-18 13:48:40.486
    SERVICE NAME:(SYS$USERS) 2008-07-18 13:48:40.484
    SESSION ID:(925.20292) 2008-07-18 13:48:40.484
    Block Checking: DBA = 528925394, Block Type = KTB-managed data block
    row 4: key out of order
    end index block validation
    for block 0x1f86c2d2
    Block header dump:  0x1f86c2d2
    Object id on Block? Y
    seg/obj: 0x2c6f0  csc: 0x00.3f418d9  itc: 2  flg: E  typ: 2 - INDEX
         brn: 0  bdba: 0x1f86c00b ver: 0x01 opc: 0
         inc: 0  exflg: 0
    Itl           Xid                  Uba         Flag  Lck        Scn/Fsc
    0x01   0x0000.000.00000000  0x00000000.0000.00  -
        0  fsc 0x0000.00000000
    0x02   0x0002.008.00002cb6  0x02475283.0359.19  --U-    2  fsc 0x0000.03f418ee
    Leaf block dump
    ===============
    header address 17494483044=0x412c0a064
    kdxcolev 0
    KDXCOLEV Flags = - - -
    kdxcolok 0
    kdxcoopc 0x80: opcode=0: iot flags=--- is converted=Y
    kdxconco 7
    kdxcosdc 0
    kdxconro 174
    kdxcofbo 384=0x180
    kdxcofeo 967=0x3c7
    kdxcoavs 583
    kdxlespl 0
    kdxlenxt 528925395=0x1f86c2d3
    kdxleprv 528925393=0x1f86c2d1
    kdxledsz 6
    kdxlebksz 8032
    row#0[7990] flag: -
    , lock: 0, len=42, data:(6):  1b ce 75 c6 00 15
    col 0; len 3; (3):  30 31 35
    col 1; len 2; (2):  58 58
    col 2; len 8; (8):  46 4f 4e 54 52 45 50 4c
    col 3; len 9; (9):  48 50 4c 4a 31 31 30 30 69
    col 4; len 3; (3):  34 36 43
    col 5; len 1; (1):  44
    col 6; len 1; (1):  80
    row#1[7952] flag: -
    , lock: 0, len=38, data:(6):  1c 46 88 34 00 0e
    col 0; len 3; (3):  30 31 35
    col 1; len 2; (2):  58 58
    col 2; len 8; (8):  46 4f 4e 54 52 45 50 4c
    col 3; len 5; (5):  48 50 4c 4a 34
    col 4; len 3; (3):  34 36 43
    col 5; len 1; (1):  44
    col 6; len 1; (1):  80
    row#2[7913] flag: -
    , lock: 0, len=39, data:(6):  1b 8f 2b bd 00 03
    col 0; len 3; (3):  30 31 35
    col 1; len 2; (2):  58 58
    col 2; len 8; (8):  46 4f 4e 54 52 45 50 4c
    col 3; len 6; (6):  48 50 4c 4a 34 30
    col 4; len 3; (3):  34 36 43
    col 5; len 1; (1):  44
    col 6; len 1; (1):  80
    row#3[7871] flag: -
    , lock: 0, len=42, data:(6):  20 03 18 b1 00 0a
    col 0; len 3; (3):  30 31 35
    col 1; len 2; (2):  58 58
    col 2; len 8; (8):  46 4f 4e 54 52 45 50 4c
    col 3; len 9; (9):  48 50 4c 4a 34 30 30 30 00
    col 4; len 3; (3):  34 36 43
    col 5; len 1; (1):  44
    col 6; len 1; (1):  80
    row#4[7830] flag: -
    , lock: 0, len=41, data:(6):  1b 4f 19 ef 00 0b
    col 0; len 3; (3):  30 31 35
    col 1; len 2; (2):  58 58
    col 2; len 8; (8):  46 4f 4e 54 52 45 50 4c
    col 3; len 8; (8):  48 50 4c 4a 34 30 30 30
    col 4; len 3; (3):  34 36 43
    col 5; len 1; (1):  44
    col 6; len 1; (1):  80
    row#5[7788] flag: -
    , lock: 0, len=42, data:(6):  21 03 15 12 00 02
    col 1; len 2; (2):  58 58
    col 2; len 8; (8):  46 4f 4e 54 52 45 50 4c
    col 3; len 9; (9):  48 50 4c 4a 34 30 30 30 31
    col 4; len 3; (3):  34 36 43
    col 5; len 1; (1):  44
    col 6; len 1; (1):  80
    row#6[7746] flag: -
    , lock: 0, len=42, data:(6):  1c 86 83 6a 00 0c
    col 0; len 3; (3):  30 31 35
    col 1; len 2; (2):  58 58
    col 2; len 8; (8):  46 4f 4e 54 52 45 50 4c
    col 3; len 9; (9):  48 50 4c 4a 34 30 30 30 37
    col 4; len 3; (3):  34 36 43
    col 5; len 1; (1):  44
    col 6; len 1; (1):  80
    row#7[7704] flag: -
    , lock: 0, len=42, data:(6):  1b 4f 19 0f 00 02
    col 0; len 3; (3):  30 31 35
    col 1; len 2; (2):  58 58
    col 2; len 8; (8):  46 4f 4e 54 52 45 50 4c
    col 3; len 9; (9):  48 50 4c 4a 34 30 30 30 44
    col 4; len 3; (3):  34 36 43
    col 5; len 1; (1):  44
    col 6; len 1; (1):  80
    row#8[7662] flag: -
    , lock: 0, len=42, data:(6):  1f 03 50 f5 00 03
    col 0; len 3; (3):  30 31 35
    col 1; len 2; (2):  58 58
    col 2; len 8; (8):  46 4f 4e 54 52 45 50 4c
    col 3; len 9; (9):  48 50 4c 4a 34 30 30 30 44
    col 4; len 3; (3):  37 30 30
    col 5; len 1; (1):  44
    col 6; len 1; (1):  80
    row#9[7619] flag: -
    , lock: 0, len=43, data:(6):  1f 03 50 f5 00 04
    col 0; len 3; (3):  30 31 35
    col 1; len 2; (2):  58 58
    col 2; len 8; (8):  46 4f 4e 54 52 45 50 4c
    col 3; len 9; (9):  48 50 4c 4a 34 30 30 30 44
    col 4; len 3; (3):  37 30 30
    col 5; len 1; (1):  44
    col 6; len 2; (2):  c1 02
    row#10[7577] flag: -
    , lock: 0, len=42, data:(6):  1f 43 21 d1 00 09
    col 0; len 3; (3):  30 31 35
    col 1; len 2; (2):  58 58
    col 2; len 8; (8):  46 4f 4e 54 52 45 50 4c
    col 3; len 9; (9):  48 50 4c 4a 34 30 30 30 45
    col 4; len 3; (3):  34 36 43
    col 5; len 1; (1):  44

  • DBVERIFY detected corrupted blocks

    Hello Gurus,
    I am facing This Error In My R-3 Server, Can Somebody Define this Error, What is a Cause And What is The Rectification of This Error ?
    Error Description
    1. BR0398E DBVERIFY detected corrupted blocks in /oracle/DBS/sapdata88/btabi_114/btabi.data114                                          
    2. BR0398E DBVERIFY detected corrupted blocks in /oracle/DBS/sapdata22/btabd_38/btabd.data38
    Waiting For An Prompt Reply

    Hello,
    I do not understand why you are asked for the BR* tools version or the oracle one.
    Resume -> you <b><u>have</u></b> corrupted blocks on your database.
    It looks like on an index datafile ( if you are lucky it is an index and it could be rebiuld ) and on a "data" datafile ( if you are lucky is on free space )
    Take a look at note <a href="http://service.sap.com/sap/support/notes/365481">365481</a>
    and to the SDN blog:
    <a href="/people/lars.breddemann/blog/2007/03/21/i-can-repair-your-corrupt-database">I can repair your corrupt database!</a>
    If one of the objects affected is a table and you do not have a good backup, probably you will lose some data.

  • Alter index ... rebuild was failing - getting corrupt blocks

    Database: 9.2.0.5
    OS: HPUX-ia64
    Hello,
    i rebuilded a index, announced from UpdatStats in DB13, and get a ORA-01114: IO error writing block to file 2045 (block # 319154) and
    ORA-27072: skgfdisp: I/O error in my sqlplus session.
    -> i do a alter index SAPR3."xxx~0" rebuild online parallel 4 nologging;
    -> System was up and running
    After that, the DBVerify marked some blocks corrupt, here one example:
    BR0398E DBVERIFY detected corrupted blocks in /oracle/XXX/sapdata22/btabi_95/btabi.data95
    We checked all corrupted blocks - all in free space.
    So we fixed that with creating a table with next extend size from the corrupted blocksize.
    I think we had not enough space in the tablespace where the index is, okay ... and what we also found, the PSAPTEMP datafiles was created as SPARSE files ...!!
    -> PSAPTEMP-Datafile: 10GB in the System - 2,5GB maximum on OS-Level, no more space.
    But my question is why i am getting corrupt blocks when a "alter index ... rebuild ..." is failing ?!?!
    Thank you for your support.
    Regards,
    Markus
    Edited by: Markus Dinkel on Oct 9, 2008 12:56 PM
    Edited by: Markus Dinkel on Oct 9, 2008 12:56 PM
    Edited by: Markus Dinkel on Oct 9, 2008 12:59 PM

    Thany you for the answer.
    I cant find any "cor" entries in the last DBVeriy log.
    I think (hope) we dont' have anymore corrupted blocks in the system.
    We get a response from SAP to update to 9.2.0.8.
    My customer wanna do a update to oracle 10 in march/april 2009, so he send me the question if we need a update to 9.2.0.8 ASAP or can we wait for the update to oralce10.
    But the important question from my customer and me is, why we get corrupt blocks after failing the alter index rebuild?
    Regards,
    Markus

  • Oracle Corrupted Blocks .

    Hi ,
        We using R/3 4.7 with Oracle 9.2 , Now i want to check any corrupted blocks are attected in our server , Can you tell me how can i check . Because i want to check the corrupted blocks in database is in online . Shall i use DBVERIFY .
    Regards
    Palani Selvan

    Palani,
    Yes You can use DBVERIFY.  You can run it from DB13-->Verify Database
    Check below note for details
    Note 23345 - Consistency check of ORACLE database
    SAP Note 354293 - DBVerify reports corrupt block in freespace area
    Note 365481 - Block corruptions
    Note 923919 - Advanced Oracle block checking features
    Just for your information, in BW system If you get warning like "DBV-00200: Block, dba 97446680, already marked corrupted", it occures because secondary indexes of InfoCube fact
    tables are set up in mode NOLOGGING as a standard.
    See below notes for more information                                                      
    Note 442763 - Avoid NOLOGGING during the index structure (Oracle
    Note 547464 - Nologging Option when creating indexes
    Note 849485 - Reconstruction of the NOLOGGING indexes after recovery
    Re: SAP_INFOCUBE_INDEXES_REPAIR
    Hope it help
    Thanks,
    Sushil

  • Error: ORA-00227 - Corrupt block detected in control file

    Hey everybody,
    I'm having problems with Oracle, here is the error displayed:
    SQL> startup;
    ORACLE instance started.
    Total System Global Area 247463936 bytes
    Fixed Size 1258244 bytes
    Variable Size 92278012 bytes
    Database Buffers 150994944 bytes
    Redo Buffers 2932736 bytes
    ORA-00227: corrupt block detected in control file: (block 16, # blocks 1)
    ORA-00202: control file: '/usr/lib/oracle/xe/oradata/XE/control.dbf'
    I wonder what I should do to solve this problem.
    Could anyone help me?
    Thanks

    user10826800 wrote:
    Hey everybody,
    I'm having problems with Oracle, here is the error displayed:
    SQL> startup;
    ORACLE instance started.
    Total System Global Area 247463936 bytes
    Fixed Size 1258244 bytes
    Variable Size 92278012 bytes
    Database Buffers 150994944 bytes
    Redo Buffers 2932736 bytes
    ORA-00227: corrupt block detected in control file: (block 16, # blocks 1)
    ORA-00202: control file: '/usr/lib/oracle/xe/oradata/XE/control.dbf'
    I wonder what I should do to solve this problem.
    Could anyone help me?
    ThanksHi and welcome to the forum. Replace corrupted control file with non-corrupted one and start the database

  • Corrupt block detected in control file

    Hi All,
    I have a scenario where I have set up Active/Standby RACs and successfully have archive redo logs being applied to Standby - everything was ok
    Versions - Oracle 11g R2 , of RHEL 5
    Scenario 1:
    Redo log application on Standby works perfectly when I do not create our software application tables using sql scripts on the Primary until AFTER the steps for Dataguard/RAC is completed successfully.
    Scenario 2:
    Redo log application does not work when I do run our sql scripts BEFORE I take a RMAN backup of the Primary to duplicate in the Standby
    Everything comes up on the Standby after the rman duplicate, archive logs get transferred , but now they do not get applied.
    I see the ORA-00227: corrupt block detected in control file: (block 1, # blocks 1) in the alert log when I put standby in Recovery Mode
    My theory is that somehow our sql scripts are breaking my rman backups when I run them before creating an RMAN backup of Primary to load on Standby- I just need someone to advise whether this is a possibility from their experience, if so I will contact Oracle support to investigate further. This is my first time working on RAC DG etc
    Thanks

    Hi All ,
    Ive tried to upgrade Oracle to 11.2.0.2 to fix this issue - that I can no longer remember !
    Managed to complete upgrade on the standby node (after having to reinstall due to hostname change )
    Now trying the Active node, I see the following error during the grid upgrade where i execute rootupgrade.sh
    Now product-specific root actions will be performed.
    Using configuration parameter file: /opt/app/11.2.0/grid2/crs/install/crsconfig_params
    Creating trace directory
    Failed to add (property/value):('OLD_OCR_ID/'-1') for checkpoint:ROOTCRS_OLDHOMEINFO.Error code is 256
    The fixes for bug 9413827 are not present in the 11.2.0.1 crs home
    Apply the patches for these bugs in the 11.2.0.1 crs home and then run rootupgrade.sh
    /opt/app/11.2.0/grid2/perl/bin/perl -I/opt/app/11.2.0/grid2/perl/lib -I/opt/app/11.2.0/grid2/crs/install /opt/app/11.2.0/grid2/crs/install/rootcrs.pl execution failed
    I have to download this patch from MOS for bug 9413827, somehow apply it to the old version of grid 11.2.0.1 and then rootupgrade.sh

  • How to identify corrupted block in Particular tablespace?

    Hi,
    i am getting lot of block corruption error from particular tablesapce datafile. i couldn't able to use DBVerify utility .bcz datafiles not created using .dbf format.
    how to idetify corrupted blocks?

    Detecting and Repairing Data Block Corruption
    http://download.oracle.com/docs/cd/B10501_01/server.920/a96521/repair.htm(9i)
    http://download.oracle.com/docs/cd/B19306_01/server.102/b14231/repair.htm(10g)
    Find more information “Handling Oracle Block Corruptions in Oracle7/8/8i/9i/10g” Metalink Note: 28814.1.
    http://dbataj.blogspot.com/2008/04/oracle-database-block-corruption.html
    http://sysdba.wordpress.com/2006/04/05/how-to-check-for-and-repair-block-corruption-with-rman-in-oracle-9i-and-oracle-10g/

  • Data corrupt block

    os Sun 5.10 oracle version 10.2.0.2 RAC 2 node
    alert.log 내용
    Hex dump of (file 206, block 393208) in trace file /oracle/app/oracle/admin/DBPGIC/udump/dbpgic1_ora_1424.trc
    Corrupt block relative dba: 0x3385fff8 (file 206, block 393208)
    Bad header found during backing up datafile
    Data in bad block:
    type: 32 format: 0 rdba: 0x00000001
    last change scn: 0x0000.98b00394 seq: 0x0 flg: 0x00
    spare1: 0x1 spare2: 0x27 spare3: 0x2
    consistency value in tail: 0x00000001
    check value in block header: 0x0
    block checksum disabled
    Reread of blocknum=393208, file=/dev/md/vg_rac06/rdsk/d119. found same corrupt data
    Reread of blocknum=393208, file=/dev/md/vg_rac06/rdsk/d119. found same corrupt data
    Reread of blocknum=393208, file=/dev/md/vg_rac06/rdsk/d119. found same corrupt data
    Reread of blocknum=393208, file=/dev/md/vg_rac06/rdsk/d119. found same corrupt data
    Reread of blocknum=393208, file=/dev/md/vg_rac06/rdsk/d119. found same corrupt data
    corrupt 발생한 Block id 를 검색해 보면 Block id 가 검색이 안됩니다.
    dba_extents 로 검색
    corrupt 때문에 Block id 가 검색이 안되는 것인지 궁금합니다.
    export 받으면 데이타는 정상적으로 export 가능.

    다행이네요. block corruption 이 발생한 곳이 데이터가 저장된 블록이
    아닌 것 같습니다. 그것도 rman백업을 통해서 발견한 것 같는데
    맞는지요?
    scn이 scn: 0x0000.00000000 가 아닌
    0x0000.98b00394 인 것으로 봐서는 physical corrupt 가 아닌
    soft corrupt인 것 같습니다.
    그렇다면 버그일 가능성이 높아서 찾아보니
    Bug 4411228 - Block corruption with mixture of file system and RAW files
    의 버그가 발견되었습니다. 이것이 아닐 수도 있지만..
    이러한 block corruption에 대한 처리방법 및 원인분석은
    오라클(주)를 통해서 정식으로 요청하셔야 합니다.
    metalink를 통해서 SR 요청을 하십시오.
    export는 high water mark 이후의 block corruption을 찾아내지 못하고 이외에도
    아래 몇가지 경우에서도 찾아내지 못합니다.
    db verify( dbv)의 경우에는 physical corruption은 찾아내지 못하고
    soft block corruption만 찾아낼 수 있습니다.
    경험상 physical corruption 이 발생하였으나 /dev/null로
    datafile copy가 안되는데도 dbv로는 이 문제를 찾아내지
    못하였습니다.
    그렇다면 가장 좋은 방법은 rman 입니다. rman은 high water mark까지의
    데이터를 백업해주면서 전체 데이터파일에 대한 체크를 하기도 합니다.
    physical corruption뿐만 아니라 logical corruption도 체크를
    하니 점검하기로는 rman이 가장 좋은 방법이라 생각합니다.
    The Export Utility
    # Use a full export to check database consistency
    # Export performs a full scan for all tables
    # Export only reads:
    - User data below the high-water mark
    - Parts of the data dictionary, while looking up information concerning the objects being exported
    # Export does not detect the following:
    - Disk corruptions above the high-water mark
    - Index corruptions
    - Free or temporary extent corruptions
    - Column data corruption (like invalid date values)
    block corruption을 정상적으로 복구하는 방법은 restore 후에
    복구하는 방법이 있겠으나 이미 restore할 백업이 block corruption이
    발생했을 수도 있습니다. 그러므로 다른 서버에 restore해보고
    정상적인 datafile인 것을 확인 후에 실환경에 restore하는 것이 좋습니다.
    만약 백업본까지 block corruption이 발생하였거나 또는 시간적 여유가
    없을 경우에는 table을 move tablespace 또는 index rebuild를 통해서
    다른 테이블스페이스로 데이터를 옮겨두고 문제가 발생한 테이블스페이스를
    drop해버리고 재생성 하는 것이 좋을 것 같습니다.(지금 현재 데이터의
    손실은 없으니 move tablespace, rebuild index 방법이 좋겠습니다.
    Handling Corruptions
    Check the alert file and system log file
    Use diagnostic tools to determine the type of corruption
    Dump blocks to find out what is wrong
    Determine whether the error persists by running checks multiple times
    Recover data from the corrupted object if necessary
    Preferred resolution method: media recovery
    Handling Corruptions
    Always try to find out if the error is permanent. Run the analyze command multiple times or, if possible, perform a shutdown and a startup and try again to perform the operation that failed earlier.
    Find out whether there are more corruptions. If you encounter one, there may be other corrupted blocks, as well. Use tools like DBVERIFY for this.
    Before you try to salvage the data, perform a block dump as evidence to identify the actual cause of the corruption.
    Make a hex dump of the bad block, using UNIX dd and od -x.
    Consider performing a redo log dump to check all the changes that were made to the block so that you can discover when the corruption occurred.
    Note: Remember that when you have a block corruption, performing media recovery is the recommended process after the hardware is verified.
    Resolve any hardware issues:
    - Memory boards
    - Disk controllers
    - Disks
    Recover or restore data from the corrupt object if necessary
    Handling Corruptions (continued)
    There is no point in continuing to work if there are hardware failures. When you encounter hardware problems, the vendor should be contacted and the machine should be checked and fixed before continuing. A full hardware diagnostics should be run.
    Many types of hardware failures are possible:
    Bad I/O hardware or firmware
    Operating system I/O or caching problem
    Memory or paging problems
    Disk repair utilities
    아래 관련 자료를 드립니다.
    All About Data Blocks Corruption in Oracle
    Vijaya R. Dumpa
    Data Block Overview:
    Oracle allocates logical database space for all data in a database. The units of database space allocation are data blocks (also called logical blocks, Oracle blocks, or pages), extents, and segments. The next level of logical database space is an extent. An extent is a specific number of contiguous data blocks allocated for storing a specific type of information. The level of logical database storage above an extent is called a segment. The high water mark is the boundary between used and unused space in a segment.
    The header contains general block information, such as the block address and the type of segment (for example, data, index, or rollback).
    Table Directory, this portion of the data block contains information about the table having rows in this block.
    Row Directory, this portion of the data block contains information about the actual rows in the block (including addresses for each row piece in the row data area).
    Free space is allocated for insertion of new rows and for updates to rows that require additional space.
    Row data, this portion of the data block contains rows in this block.
    Analyze the Table structure to identify block corruption:
    By analyzing the table structure and its associated objects, you can perform a detailed check of data blocks to identify block corruption:
    SQL> analyze table_name/index_name/cluster_name ... validate structure cascade;
    Detecting data block corruption using the DBVERIFY Utility:
    DBVERIFY is an external command-line utility that performs a physical data structure integrity check on an offline database. It can be used against backup files and online files. Integrity checks are significantly faster if you run against an offline database.
    Restrictions:
    DBVERIFY checks are limited to cache-managed blocks. It’s only for use with datafiles, it will not work against control files or redo logs.
    The following example is sample output of verification for the data file system_ts_01.dbf. And its Start block is 9 and end block is 25. Blocksize parameter is required only if the file to be verified has a non-2kb block size. Logfile parameter specifies the file to which logging information should be written. The feedback parameter has been given the value 2 to display one dot on the screen for every 2 blocks processed.
    $ dbv file=system_ts_01.dbf start=9 end=25 blocksize=16384 logfile=dbvsys_ts.log feedback=2
    DBVERIFY: Release 8.1.7.3.0 - Production on Fri Sep 13 14:11:52 2002
    (c) Copyright 2000 Oracle Corporation. All rights reserved.
    Output:
    $ pg dbvsys_ts.log
    DBVERIFY: Release 8.1.7.3.0 - Production on Fri Sep 13 14:11:52 2002
    (c) Copyright 2000 Oracle Corporation. All rights reserved.
    DBVERIFY - Verification starting : FILE = system_ts_01.dbf
    DBVERIFY - Verification complete
    Total Pages Examined : 17
    Total Pages Processed (Data) : 10
    Total Pages Failing (Data) : 0
    Total Pages Processed (Index) : 2
    Total Pages Failing (Index) : 0
    Total Pages Processed (Other) : 5
    Total Pages Empty : 0
    Total Pages Marked Corrupt : 0
    Total Pages Influx : 0
    Detecting and reporting data block corruption using the DBMS_REPAIR package:
    Note: Note that this event can only be used if the block "wrapper" is marked corrupt.
    Eg: If the block reports ORA-1578.
    1. Create DBMS_REPAIR administration tables:
    To Create Repair tables, run the below package.
    SQL> EXEC DBMS_REPAIR.ADMIN_TABLES(‘REPAIR_ADMIN’, 1,1, ‘REPAIR_TS’);
    Note that table names prefix with ‘REPAIR_’ or ‘ORPAN_’. If the second variable is 1, it will create ‘REAIR_key tables, if it is 2, then it will create ‘ORPAN_key tables.
    If the thread variable is
    1 then package performs ‘create’ operations.
    2 then package performs ‘delete’ operations.
    3 then package performs ‘drop’ operations.
    2. Scanning a specific table or Index using the DBMS_REPAIR.CHECK_OBJECT procedure:
    In the following example we check the table employee for possible corruption’s that belongs to the schema TEST. Let’s assume that we have created our administration tables called REPAIR_ADMIN in schema SYS.
    To check the table block corruption use the following procedure:
    SQL> VARIABLE A NUMBER;
    SQL> EXEC DBMS_REPAIR.CHECK_OBJECT (‘TEST’,’EMP’, NULL,
    1,’REPAIR_ADMIN’, NULL, NULL, NULL, NULL,:A);
    SQL> PRINT A;
    To check which block is corrupted, check in the REPAIR_ADMIN table.
    SQL> SELECT * FROM REPAIR_ADMIN;
    3. Fixing corrupt block using the DBMS_REPAIR.FIX_CORRUPT_BLOCK procedure:
    SQL> VARIABLE A NUMBER;
    SQL> EXEC DBMS_REPAIR.FIX.CORRUPT_BLOCKS (‘TEST’,’EMP’, NULL,
    1,’REPARI_ADMIN’, NULL,:A);
    SQL> SELECT MARKED FROM REPAIR_ADMIN;
    If u select the EMP table now you still get the error ORA-1578.
    4. Skipping corrupt blocks using the DBMS_REPAIR. SKIP_CORRUPT_BLOCK procedure:
    SQL> EXEC DBMS_REPAIR. SKIP_CORRUPT.BLOCKS (‘TEST’, ‘EMP’, 1,1);
    Notice the verification of running the DBMS_REPAIR tool. You have lost some of data. One main advantage of this tool is that you can retrieve the data past the corrupted block. However we have lost some data in the table.
    5. This procedure is useful in identifying orphan keys in indexes that are pointing to corrupt rows of the table:
    SQL> EXEC DBMS_REPAIR. DUMP ORPHAN_KEYS (‘TEST’,’IDX_EMP’, NULL,
    2, ‘REPAIR_ADMIN’, ‘ORPHAN_ADMIN’, NULL,:A);
    If u see any records in ORPHAN_ADMIN table you have to drop and re-create the index to avoid any inconsistencies in your queries.
    6. The last thing you need to do while using the DBMS_REPAIR package is to run the DBMS_REPAIR.REBUILD_FREELISTS procedure to reinitialize the free list details in the data dictionary views.
    SQL> EXEC DBMS_REPAIR.REBUILD_FREELISTS (‘TEST’,’EMP’, NULL, 1);
    NOTE
    Setting events 10210, 10211, 10212, and 10225 can be done by adding the following line for each event in the init.ora file:
    Event = "event_number trace name errorstack forever, level 10"
    When event 10210 is set, the data blocks are checked for corruption by checking their integrity. Data blocks that don't match the format are marked as soft corrupt.
    When event 10211 is set, the index blocks are checked for corruption by checking their integrity. Index blocks that don't match the format are marked as soft corrupt.
    When event 10212 is set, the cluster blocks are checked for corruption by checking their integrity. Cluster blocks that don't match the format are marked as soft corrupt.
    When event 10225 is set, the fet$ and uset$ dictionary tables are checked for corruption by checking their integrity. Blocks that don't match the format are marked as soft corrupt.
    Set event 10231 in the init.ora file to cause Oracle to skip software- and media-corrupted blocks when performing full table scans:
    Event="10231 trace name context forever, level 10"
    Set event 10233 in the init.ora file to cause Oracle to skip software- and media-corrupted blocks when performing index range scans:
    Event="10233 trace name context forever, level 10"
    To dump the Oracle block you can use below command from 8.x on words:
    SQL> ALTER SYSTEM DUMP DATAFILE 11 block 9;
    This command dumps datablock 9 in datafile11, into USER_DUMP_DEST directory.
    Dumping Redo Logs file blocks:
    SQL> ALTER SYSTEM DUMP LOGFILE ‘/usr/oracle8/product/admin/udump/rl. log’;
    Rollback segments block corruption, it will cause problems (ORA-1578) while starting up the database.
    With support of oracle, can use below under source parameter to startup the database.
    CORRUPTEDROLLBACK_SEGMENTS=(RBS_1, RBS_2)
    DB_BLOCK_COMPUTE_CHECKSUM
    This parameter is normally used to debug corruption’s that happen on disk.
    The following V$ views contain information about blocks marked logically corrupt:
    V$ BACKUP_CORRUPTION, V$COPY_CORRUPTION
    When this parameter is set, while reading a block from disk to catch, oracle will compute the checksum again and compares it with the value that is in the block.
    If they differ, it indicates that the block is corrupted on disk. Oracle makes the block as corrupt and signals an error. There is an overhead involved in setting this parameter.
    DB_BLOCK_CACHE_PROTECT=‘TRUE’
    Oracle will catch stray writes made by processes in the buffer catch.
    Oracle 9i new RMAN futures:
    Obtain the datafile numbers and block numbers for the corrupted blocks. Typically, you obtain this output from the standard output, the alert.log, trace files, or a media management interface. For example, you may see the following in a trace file:
    ORA-01578: ORACLE data block corrupted (file # 9, block # 13)
    ORA-01110: data file 9: '/oracle/dbs/tbs_91.f'
    ORA-01578: ORACLE data block corrupted (file # 2, block # 19)
    ORA-01110: data file 2: '/oracle/dbs/tbs_21.f'
    $rman target =rman/rman@rmanprod
    RMAN> run {
    2> allocate channel ch1 type disk;
    3> blockrecover datafile 9 block 13 datafile 2 block 19;
    4> }
    Recovering Data blocks Using Selected Backups:
    # restore from backupset
    BLOCKRECOVER DATAFILE 9 BLOCK 13 DATAFILE 2 BLOCK 19 FROM BACKUPSET;
    # restore from datafile image copy
    BLOCKRECOVER DATAFILE 9 BLOCK 13 DATAFILE 2 BLOCK 19 FROM DATAFILECOPY;
    # restore from backupset with tag "mondayAM"
    BLOCKRECOVER DATAFILE 9 BLOCK 13 DATAFILE 2 BLOCK 199 FROM TAG = mondayAM;
    # restore using backups made before one week ago
    BLOCKRECOVER DATAFILE 9 BLOCK 13 DATAFILE 2 BLOCK 19 RESTORE
    UNTIL 'SYSDATE-7';
    # restore using backups made before SCN 100
    BLOCKRECOVER DATAFILE 9 BLOCK 13 DATAFILE 2 BLOCK 19 RESTORE UNTIL SCN 100;
    # restore using backups made before log sequence 7024
    BLOCKRECOVER DATAFILE 9 BLOCK 13 DATAFILE 2 BLOCK 19 RESTORE
    UNTIL SEQUENCE 7024;
    글 수정:
    Min Angel (Yeon Hong Min, Korean)

  • Recovery is repairing media corrupt block x of file x in standby alert log

    Hi,
    oracle version:8.1.7.0.0
    os version :solaris  5.9
    we have oracle 8i primary and standby database. i am getting erorr in alert log file:
    Thu Aug 28 22:48:12 2008
    Media Recovery Log /oratranslog/arch_1_1827391.arc
    Thu Aug 28 22:50:42 2008
    Media Recovery Log /oratranslog/arch_1_1827392.arc
    bash-2.05$ tail -f alert_pindb.log
    Recovery is repairing media corrupt block 991886 of file 179
    Recovery is repairing media corrupt block 70257 of file 184
    Recovery is repairing media corrupt block 70258 of file 184
    Recovery is repairing media corrupt block 70259 of file 184
    Recovery is repairing media corrupt block 70260 of file 184
    Recovery is repairing media corrupt block 70261 of file 184
    Thu Aug 28 22:48:12 2008
    Media Recovery Log /oratranslog/arch_1_1827391.arc
    Thu Aug 28 22:50:42 2008
    Media Recovery Log /oratranslog/arch_1_1827392.arc
    Recovery is repairing media corrupt block 500027 of file 181
    Recovery is repairing media corrupt block 500028 of file 181
    Recovery is repairing media corrupt block 500029 of file 181
    Recovery is repairing media corrupt block 500030 of file 181
    Recovery is repairing media corrupt block 500031 of file 181
    Recovery is repairing media corrupt block 991837 of file 179
    Recovery is repairing media corrupt block 991838 of file 179
    how i can resolve this.
    [pre]
    Thanks
    Prakash
    Edited by: user612485 on Aug 28, 2008 10:53 AM                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                       

    Dear satish kandi,
    recently we have created index for one table with nologgign option, i think for that reason i am getting that error.
    if i run dbv utility on the files which are shown in alert log file i am getting the following results.
    bash-2.05$ dbv file=/oracle15/oradata/pindb/pinx055.dbf blocksize=4096
    DBVERIFY: Release 8.1.7.0.0 - Production on Fri Aug 29 12:18:27 2008
    (c) Copyright 2000 Oracle Corporation. All rights reserved.
    DBVERIFY - Verification starting : FILE = /oracle15/oradata/pindb/pinx053.dbf
    Block Checking: DBA = 751593895, Block Type =
    Found block already marked corrupted
    Block Checking: DBA = 751593896, Block Type =
    .DBVERIFY - Verification complete
    Total Pages Examined : 1048576
    Total Pages Processed (Data) : 0
    Total Pages Failing (Data) : 0
    Total Pages Processed (Index): 1036952
    Total Pages Failing (Index): 0
    Total Pages Processed (Other): 7342
    Total Pages Empty : 4282
    Total Pages Marked Corrupt : 0
    Total Pages Influx : 0
    bash-2.05$ dbv file=/oracle15/oradata/pindb/pinx053.dbf blocksize=4096
    DBVERIFY: Release 8.1.7.0.0 - Production on Fri Aug 29 12:23:12 2008
    (c) Copyright 2000 Oracle Corporation. All rights reserved.
    DBVERIFY - Verification starting : FILE = /oracle15/oradata/pindb/pinx054.dbf
    Block Checking: DBA = 759492966, Block Type =
    Found block already marked corrupted
    Block Checking: DBA = 759492967, Block Type =
    Found block already marked corrupted
    Block Checking: DBA = 759492968, Block Type =
    .DBVERIFY - Verification complete
    Total Pages Examined : 1048576
    Total Pages Processed (Data) : 0
    Total Pages Failing (Data) : 0
    Total Pages Processed (Index): 585068
    Total Pages Failing (Index): 0
    Total Pages Processed (Other): 8709
    Total Pages Empty : 454799
    Total Pages Marked Corrupt : 0
    Total Pages Influx : 0
    bash-2.05$ dbv file=/oracle15/oradata/pindb/pinx054.dbf blocksize=4096
    DBVERIFY: Release 8.1.7.0.0 - Production on Fri Aug 29 12:32:28 2008
    (c) Copyright 2000 Oracle Corporation. All rights reserved.
    DBVERIFY - Verification starting : FILE = /oracle15/oradata/pindb/pinx055.dbf
    Block Checking: DBA = 771822208, Block Type =
    Found block already marked corrupted
    Block Checking: DBA = 771822209, Block Type =
    Found block already marked corrupted
    Block Checking: DBA = 771822210, Block Type =
    .DBVERIFY - Verification complete
    Total Pages Examined : 1048576
    Total Pages Processed (Data) : 0
    Total Pages Failing (Data) : 0
    Total Pages Processed (Index): 157125
    Total Pages Failing (Index): 0
    Total Pages Processed (Other): 4203
    Total Pages Empty : 887248
    Total Pages Marked Corrupt : 0
    Total Pages Influx : 0
    My doubts are :
    1.if i drop the index and recreate the index with logging option will this error won't repeat in alert log file
    2.in future if i activate the standby database will database is going to open without any error.
    Thanks
    Prakash
    .

  • ORA-19566: exceeded limit of 0 corrupt blocks

    Hi All,
    We have been encountering some issues with RMAN backup; it has been erroring out with same errors (max corrupt blocks). As of now, I ran the db verify for affected files and found that indexes are failing. When I tried to find out the indexes from extent views, I was unable to find it. Looks like these blocks are in free space as I found it and also the V$backup corruption view shows the logical corruption.
    Waiting for you suggestion....
    BANNER
    Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 - 64bi
    PL/SQL Release 10.2.0.3.0 - Production
    CORE 10.2.0.3.0 Production
    TNS for HPUX: Version 10.2.0.3.0 - Production
    NLSRTL Version 10.2.0.3.0 - Production
    RMAN LOG:
    channel a3: starting piece 1 at 14-DEC-09
    RMAN-03009: failure of backup command on a2 channel at 12/14/2009 05:43:42
    ORA-19566: exceeded limit of 0 corrupt blocks for file /ub834/oradata/TERP/applsysd142.dbf
    continuing other job steps, job failed will not be re-run
    channel a2: starting incremental level 0 datafile backupset
    channel a2: specifying datafile(s) in backupset
    including current control file in backupset
    channel a2: starting piece 1 at 14-DEC-09
    channel a1: finished piece 1 at 14-DEC-09
    piece handle=TERP_1769708180_level0_292_1_1_20091213065437.rmn tag=TAG20091213T065459 comment=API Version 2.0,MMS Version 5.0.0.0
    channel a1: backup set complete, elapsed time: 01:14:45
    channel a2: finished piece 1 at 14-DEC-09
    piece handle=TERP_1769708180_level0_296_1_1_20091213065437.rmn tag=TAG20091213T065459 comment=API Version 2.0,MMS Version 5.0.0.0
    channel a2: backup set complete, elapsed time: 00:24:54
    RMAN-03009: failure of backup command on a4 channel at 12/14/2009 06:14:33
    ORA-19566: exceeded limit of 0 corrupt blocks for file /ub834/oradata/TERP/applsysd143.dbf
    continuing other job steps, job failed will not be re-run
    released channel: a1
    released channel: a2
    released channel: a3
    released channel: a4
    RMAN-00571: ===========================================================
    RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
    RMAN-00571: ===========================================================
    RMAN-03009: failure of backup command on a3 channel at 12/14/2009 06:41:00
    ORA-19566: exceeded limit of 0 corrupt blocks for file /ub806/oradata/TERP/icxd01.dbf
    Recovery Manager complete.
    Thanks,
    Vimlendu
    Edited by: Vimlendu on Dec 20, 2009 10:27 AM

    dbv file=/ora/oradata/binadb/RAT_TRANS_IDX01.dbf blocksize=8192
    The result:
    DBVERIFY: Release 10.2.0.3.0 - Production on Thu Nov 20 11:14:01 2003
    (c) Copyright 2000 Oracle Corporation. All rights reserved.
    DBVERIFY - Verification starting : FILE =
    /ora/oradata/binadb/RAT_TRANS_IDX01.dbf
    Block Checking: DBA = 75520968, Block Type = KTB-managed data block
    **** row 80: key out of order
    ---- end index block validation
    Page 23496 failed with check code 6401
    DBVERIFY - Verification complete
    Total Pages Examined : 34560
    Total Pages Processed (Data) : 1
    Total Pages Failing (Data) : 0
    Total Pages Processed (Index): 31084
    Total Pages Failing (Index): 1
    Total Pages Processed (Other): 191
    Total Pages Empty : 3284
    Total Pages Marked Corrupt : 0
    Total Pages Influx : 0
    Seems like I have 1 page failing. I try to run this script:
    select segment_type, segment_name, owner
    from sys.dba_extents
    where file_id = 18 and 23496 between block_id
    and block_id + blocks - 1;
    No rows returned.
    Then, I try to run this script:
    Select tablespace_name, file_id, block_id, bytes
    from dba_free_space
    where file_id = 18
    and 23496 between block_id and block_id + blocks - 1
    Resulting 1 row.
    Seems like I have the possible corrupt block on unused space.
    Edited by: Vimlendu on Dec 20, 2009 2:30 PM
    Edited by: Vimlendu on Dec 20, 2009 2:41 PM

  • Strange Corrupt Block Error in Control File not in CONTROL_FILES

    When in RMAN connected to the TARGET and CATALOG I issue a RESYNC CATALOG I get this error:
    RMAN> RESYNC CATALOG;
    RMAN-00571: ===========================================================
    RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
    RMAN-00571: ===========================================================
    RMAN-03009: failure of resync command on default channel at 08/17/2009 10:36:59
    ORA-00227: corrupt block detected in control file: (block 15, # blocks 1)
    ORA-00202: control file: 'E:\ORACLE\PRODUCT\10.2.0\DATABASE\SNCFEBIZ01PD.ORA'
    RMAN>
    This control file is in the Oracle Windows default dir but I am not using it and did not create it.
    My control files listed in the init.ora are:
    SQL> show parameter control
    NAME TYPE VALUE
    control_file_record_keep_time integer 7
    control_files string E:\ORACLE\ORADATA\EBIZ01PD\CNT
    RL01.DBF, D:\ORACLE\ORADATA\EB
    IZ01PD\CNTRL02.DBF, E:\ORACLE\
    ORADATA\EBIZ01PD\CNTRL03.DBF
    Any idea why this is happening?

    That is a SNAPSHOT CONTROLFILE, created by RMAN as a copy of the current controlfile.
    Wonder how and why the copy is corrupted ? Check the timestamp of the file to see when it was created. A RESYNC will always create a fresh Snapshot Controlfile.
    See http://download.oracle.com/docs/cd/B19306_01/backup.102/b14191/rcmarchi.htm#sthref65

  • How to make a corrupted block?

    Hi all,
    Is there any method to make a block corrupted in Oracle (for Windows)?
    My target is to test detecting and repairing corrupted blocks tools in Oracle.
    Thanks in advance,
    Ahmed B.

    Its not a great practice to do and oracle doesn't recommend such act. However, Oracle Support they have some internal utility for such, I dont know whether it is available to public or not. Search at metalink.
    Jaffar
    I just reaclled, there is a utility called 'bbed' which comes with oracle.
    However in UNIX you can use the dd command to corrupt a few blocks.Something like
    dd ibs=db_block_Size skip=n count=n if=/dev/null of=full_path_name_of_file_to_corrupt
    You can use the freeware hexedit to simulate block corruption in Windows.
    My sincere request is that dont do this with your production db. Use it very caciously.
    Message was edited by:
    The Human Fly

  • Help Fix 26473 Corrupt blocks in system09.dbf

    How to Format Corrupted Block Not Part of Any Segment [ID 336133.1]
    I'm following the above doc to fix 26K corrupt blocks in system09.dbf
    in Step 7 of the Doc it says:
    +" First find the *extent size* by querying dba_free_space "+
    +65536 = If its 64 K+
    +1048576 = 1M+
    I'm getting 891559936 with the following query:
    SQL> Select bytes from dba_free_space where file_id= 352 and 192128 between block_id and block_id + blocks -1;
    BYTES
    891559936
    What will be my extent size?
    I'm lost on how to proceed with the following steps:
    BEGIN
    for i in 1..1000000 loop
    EXECUTE IMMEDIATE 'alter table apps.s allocate extent (DATAFILE '||'''/oracle/KPSO/db/apps_st/data/system09.dbf''' ||'SIZE 64K) ';
    end loop;
    end ;
    +/+
    Note you need to change accordingly the size (1M ,64K or 128k) and the value of for loop
    can be changed as per requirement.
    Thanks.
    -Joey-

    >
    currently doing another round of steps 5-9 to see if it will wipe out all the corrupt blocks.Just want to give an update:
    Datafile was completely free of corruption after 2 more passes ..
    $ dbv file=/oracle/KPSO/db/apps_st/data/system09.dbf blocksize=8192
    DBVERIFY: Release 11.1.0.7.0 - Production on Thu Mar 22 05:08:56 2012
    Copyright (c) 1982, 2007, Oracle. All rights reserved.
    DBVERIFY - Verification starting : FILE = /oracle/KPSO/db/apps_st/data/system09.dbf
    DBVERIFY - Verification complete
    Total Pages Examined : 192128
    Total Pages Processed (Data) : 160979
    Total Pages Failing (Data) : 0
    Total Pages Processed (Index): 26455
    Total Pages Failing (Index): 0
    Total Pages Processed (Other): 2124
    Total Pages Processed (Seg) : 0
    Total Pages Failing (Seg) : 0
    Total Pages Empty : 2570
    Total Pages Marked Corrupt : 0
    Total Pages Influx : 0
    Total Pages Encrypted : 0
    Highest block SCN : 3757005752 (1388.3757005752)

  • All corrupted blocks

    Hi,
    in 10g R2, any query to see all corrupted blocks and their owners ?
    Thank you.

    Hi,
    thanks to all. But I'm confused :
    SQL> select count(*) FROM sometable;
    select count(*) FROM sometable
    ERROR at line 1:
    ORA-01578: ORACLE data block corrupted (file # 3, block # 27080)
    ORA-01110: data file 3: 'D:\BASE\TEST\DATA\SYSAUX01.DBF'
    SQL> select file#, block# from V$DATABASE_BLOCK_CORRUPTION;
    no rows selected
    dbv file='D:\BASE\TEST\DATA\SYSAUX01.DBF' blocksize=8192
    DBVERIFY: Release 10.2.0.1.0 - Production on Sun Jul 5 17:20:04 2009
    Copyright (c) 1982, 2005, Oracle.  All rights reserved.
    DBVERIFY - Verification starting : FILE = D:\BASE\TEST\DATA\SYSAUX01.DBF
    DBV-00200: Block, dba 12609992, already marked corrupted
    DBV-00200: Block, dba 12610792, already marked corrupted
    DBV-00200: Block, dba 12611016, already marked corrupted
    DBV-00200: Block, dba 12612680, already marked corruptedWhy no rows selected from V$DATABASE_BLOCK_CORRUPTION ??
    Thank for any explanation.

Maybe you are looking for

  • Problem to update data in a Customized table

    Hi, I want to update the internal tables record into a ztable i am using Loop at itab. UPDATE ZTABLE Endloop. Comit Work. this program is running fine in Test environment but while i run in some other environment the fields are updated correctly exce

  • Is there any way to find out what the Ext Id is that is assigned to CRM records

    Whilst there is a lot of confusion as to when and where you use this field and what is the unique record key for some, I have understood that however what I am wanting to find is excatly what is the external ID that was assigned to the CRM record whe

  • Nano will not sync with windows 8.1

    Recently installed windows 8.1 and cannot sync nano.  Restored to factory settings, but will not download songs from my itunes library to nano

  • [LiveCycle Designer] Send Field Value with FDF Response

    Hiya. I'm trying to send two FDF responses, a status message and a field/pair value, from a PHP script that has processed a HTTP POST. The status message is sent to the form successfully, but the field value is not sent to a form created in LiveCycle

  • DB access in JSP ignored

    <p>Hi everybody</p><p>I created a report in Eclipse against a local MySQL, embedded it in a JSP and deployed it on a local Tomcat for testing. Evrything went smooth but when I reasign an identical remote DB to the report, copy the Web Archive onto a