Zero Block Corruption in SE Environment.

Environment: 11g Using Standard Edition of Rracle in Windows environment.
I'm having difficulties finding any article or support documents for Zero block corruption issues at logical level.
If i took Export of the full database, and have no errors. does that count as safe data.
Does EXPDP skip the such error like block corruption. What are the option beyond the expdp to find any block level corruption

>What are the option beyond the expdp to find any block level corruption
run dbv against desired datafile
[oracle@localhost ~]$ dbv
DBVERIFY: Release 11.2.0.2.0 - Production on Tue Apr 21 12:39:28 2015
Copyright (c) 1982, 2009, Oracle and/or its affiliates.  All rights reserved.
Keyword     Description                    (Default)
FILE        File to Verify                 (NONE)
START       Start Block                    (First Block of File)
END         End Block                      (Last Block of File)
BLOCKSIZE   Logical Block Size             (8192)
LOGFILE     Output Log                     (NONE)
FEEDBACK    Display Progress               (0)
PARFILE     Parameter File                 (NONE)
USERID      Username/Password              (NONE)
SEGMENT_ID  Segment ID (tsn.relfile.block) (NONE)
HIGH_SCN    Highest Block SCN To Verify    (NONE)
            (scn_wrap.scn_base OR scn)          
[oracle@localhost ~]$

Similar Messages

  • SYSTEM TS Corruption - Zero Blocks

    One of our production instances use operating system level COPY as backup method. When we tried to implement rman backups, we came to know there are some zero blocks in system tablespace. after doing a DBV on the datafile noted by rman, we found there are 12 corrupt/zero pages in system03.dbf.
    We cannot go to a backup and roll forward, because we dont know since when this system03 is corrupt. The only option that comes to mind is a full export and rebuild of the database. This is an oracle applications db and pretty critical. The size is around 300GB. We cant afford that much downtime on production.
    Any ideas ? so far we didnt have any reported issues due to this corruption. The corrupted object in SYS.IDL_UB1$.
    ++DBV LOG :-++
    DBVERIFY: Release 10.2.0.3.0 - Production on Thu Dec 11 11:00:26 2008
    Copyright (c) 1982, 2005, Oracle. All rights reserved.
    DBVERIFY - Verification starting : FILE = system03.dbf
    Page 191938 is influx - most likely media corrupt
    Corrupt block relative dba: 0x00c2edc2 (file 3, block 191938)
    Fractured block found during dbv:
    Data in bad block:
    type: 0 format: 2 rdba: 0x00c2edc2
    last change scn: 0x0000.00000000 seq: 0x1 flg: 0x05
    spare1: 0x0 spare2: 0x0 spare3: 0x0
    consistency value in tail: 0x00000000
    check value in block header: 0xea00
    computed block checksum: 0x1
    Page 191939 is marked corrupt
    Corrupt block relative dba: 0x00c2edc3 (file 3, block 191939)
    Completely zero block found during dbv:
    Page 191940 is marked corrupt
    Corrupt block relative dba: 0x00c2edc4 (file 3, block 191940)
    Completely zero block found during dbv:
    Page 191941 is marked corrupt
    Corrupt block relative dba: 0x00c2edc5 (file 3, block 191941)
    Completely zero block found during dbv:
    Page 191942 is marked corrupt
    Corrupt block relative dba: 0x00c2edc6 (file 3, block 191942)
    Completely zero block found during dbv:
    Page 191943 is marked corrupt
    Corrupt block relative dba: 0x00c2edc7 (file 3, block 191943)
    Completely zero block found during dbv:
    Page 191944 is marked corrupt
    Corrupt block relative dba: 0x00c2edc8 (file 3, block 191944)
    Completely zero block found during dbv:
    Page 191945 is marked corrupt
    Corrupt block relative dba: 0x00c2edc9 (file 3, block 191945)
    Completely zero block found during dbv:
    Page 191946 is marked corrupt
    Corrupt block relative dba: 0x00c2edca (file 3, block 191946)
    Completely zero block found during dbv:
    Page 191947 is marked corrupt
    Corrupt block relative dba: 0x00c2edcb (file 3, block 191947)
    Completely zero block found during dbv:
    Page 191948 is marked corrupt
    Corrupt block relative dba: 0x00c2edcc (file 3, block 191948)
    Completely zero block found during dbv:
    Page 191949 is influx - most likely media corrupt
    Corrupt block relative dba: 0x00c2edcd (file 3, block 191949)
    Fractured block found during dbv:
    Data in bad block:
    type: 0 format: 0 rdba: 0x00000000
    last change scn: 0x0000.00000000 seq: 0x0 flg: 0x00
    spare1: 0x0 spare2: 0x0 spare3: 0x0
    consistency value in tail: 0x00000001
    check value in block header: 0x0
    block checksum disabled
    DBVERIFY - Verification complete
    Total Pages Examined : 256000
    Total Pages Processed (Data) : 128521
    Total Pages Failing (Data) : 0
    Total Pages Processed (Index): 52973
    Total Pages Failing (Index): 0
    Total Pages Processed (Other): 493
    Total Pages Processed (Seg) : 0
    Total Pages Failing (Seg) : 0
    Total Pages Empty : 74001
    Total Pages Marked Corrupt : 12
    Total Pages Influx : 2
    Highest block SCN : 1191398275 (1.1191398275)
    Edited by: Lakshmi Pavuluri on Dec 11, 2008 11:30 AM

    I think Oracle support is playing it safe. With damaged system tablespace without backup, that's logical conclusion.
    Did you try run hcheck.sql to get a report?
    "hcheck.sql" script to check for known problems in Oracle8i,Oracle9i, Oracle10g and Oracle 11g
    Doc ID: Note:136697.1
    Do some DML on table SYS.IDL_UB1$ see you get any error.
    This metalink doc has some info on fixing damaged database dictionary.
    ORA-8103 Diagnostics and Solution
    Doc ID: Note:268302.1
    The error just mean the block has been zeroed out a common type of corruption.

  • Reports are not able to run coz of Block Corruption

    Hi all,
    I have reported some Oracle finance reports are not running.
    Once i got the call i looked into the user trace file, there i found the below :
    Corrupt block dba: 0x2100f345 file=33. blocknum=62277. found during buffer read
    on disk type:0. ver:0. dba: 0x00000000 inc:0x00000000 seq:0x00000000 incseq:0x00000000
    Entire contents of block is zero - block never written
    Reread of block=2100f345 file=33. blocknum=62277. found same corupted data
    table scan: segment: file# 15 block# 84
    skipping corrupt block file# 33 block# 62277
    Corrupt block dba: 0x2100f346 file=33. blocknum=62278. found during buffer read
    on disk type:0. ver:0. dba: 0x00000000 inc:0x00000000 seq:0x00000000 incseq:0x00000000
    Entire contents of block is zero - block never written
    Reread of block=2100f346 file=33. blocknum=62278. found same corupted data
    table scan: segment: file# 15 block# 84
    skipping corrupt block file# 33 block# 62278
    Then i try to find out which table is affected by the below queary :
    SQL> select segment_type,owner,segment_name from dba_extents where file_id=33 and 62278 between block_id and block_idblocks -1;+
    SEGMENT_TYPE      OWNER
    SEGMENT_NAME
    TABLE             GL
    GL_JE_LINES
    So this above table GL_JE_LINES is the affected table is init.
    Now what is the action i have to take. In this database there is no archive log enabled and version of this database is 7.
    Can any one sugges me what is the action i have to take now.
    Regards
    Hamid

    DB version :
    SQL> select * from v$version;
    BANNER
    Oracle7 Server Release 7.3.4.3.0 - Production
    PL/SQL Release 2.3.4.3.0 - Production
    CORE Version 3.5.4.0.0 - Production
    TNS for IBM/AIX RISC System/6000: Version 2.3.4.0.0 - Production
    NLSRTL Version 3.2.4.0.0 - Production
    Alert log :
    SID>tail -f alert_SID.log
    Tue Sep 25 14:35:03 2012
    Errors in file /u20/app/oracle/admin/APRD/udump/ora_84426_aprd.trc:
    Tue Sep 25 14:35:03 2012
    Errors in file /u20/app/oracle/admin/APRD/udump/ora_84426_aprd.trc:
    Tue Sep 25 14:35:03 2012
    Errors in file /u20/app/oracle/admin/APRD/udump/ora_84426_aprd.trc:
    Tue Sep 25 15:09:18 2012
    create tablespace tbs datafile '/stage/software/APRD/oradata/tbsnew.dbf' size 10                                                                             0m
    Tue Sep 25 15:09:27 2012
    Completed: create tablespace tbs datafile '/stage/software/AP...
    Trace file :
    SID>tail -f ora_84426_aprd.trc
    on disk type:0. ver:0. dba: 0x00000000 inc:0x00000000 seq:0x00000000 incseq:0x00000000
    Entire contents of block is zero - block never written
    Reread of block=2101d366 file=33. blocknum=119654. found same corupted data
    table scan: segment: file# 15 block# 84
    skipping corrupt block file# 33 block# 119654
    Corrupt block dba: 0x2101d367 file=33. blocknum=119655. found during buffer read
    on disk type:0. ver:0. dba: 0x00000000 inc:0x00000000 seq:0x00000000 incseq:0x00000000
    Entire contents of block is zero - block never written
    Reread of block=2101d367 file=33. blocknum=119655. found same corupted
    For this above :
    SQL> select segment_type,owner,segment_name from dba_extents where file_id=33 and 119654 between block_id and block_id+blocks -1;
    SEGMENT_TYPE      OWNER
    SEGMENT_NAME
    TABLE             GL
    GL_JE_LINES
    Regards
    Hamid

  • Interpration of DBVerify zero block  errors

    Hello Oracle-experts,
    after DBVerify check on my Oracle DB 10.2.0.2 i get the several following errors:
    Completely zero block found during dbv:
    Page 286685 is marked corrupt
    After these warnings I get the error:
    BR0398E DBVERIFY detected corrupted blocks in /oracle/<sid>/sapdata4/sr3_8/sr3.data8
    Question:
    1) How should these zero block errors be interpreted?  Is my database therefore corrupt or can these errors be neglected?  If not, what is the approach to solve these errors?
    The problem is that I have a lot of these errors and do not have a valid backup.
    Any helpful information information will be very appreciated!

    Hi Holger,
    didn't you like the replies of your other threads?
    Block Corruption (BR0398E DBVERIFY detected corrupted blocks in /oracle/TS2
    BR0398E DBVERIFY detected corrupted blocks in TS SAPSR3
    Honestly, handling corruptions is really not that difficult.
    You figure out what kind of data is supposed to be stored in the corrupted blocks and take your actions accordingly.
    So if you can regenerate the content (like you can do that by rebuilding indexes), you do that.
    If you cannot regenerate the content, you need a backup.
    That's it. It's all lengthly described in the SAP notes on corruptions. Maybe you should read them ...
    > Question:
    > 1) How should these zero block errors be interpreted?  Is my database therefore corrupt or can these errors be neglected?  If not, what is the approach to solve these errors?
    > The problem is that I have a lot of these errors and do not have a valid backup.
    Ok, having no backups always puts you in dire straits. It's the single one error no DBA is allowed to make.
    However, what you should do is to perform a FULL consistency check.
    That is:
    run ANALYZE TABLE VALIDATE STRUCTURE CASCADE on ALL tables
    run a FULL db export to /dev/nul
    run DBVerify/RMAN validate on the complete database (looks like you've already done that)
    Don't skip a check, don't shortcut - just do them.
    Maybe the "completely zero filled blocks* don't belong to any object and you've no data loss.
    Then you may (as I already told you in the other thread) reorganize the tablespace to get rid of the warnings.
    If there was some data in these blocks that you cannot regenerate then you have to face it: you lost that data.
    It's gone and won't come back.
    regards,
    Lars

  • Block corruption in Free Space

    Hi,
    Environment:-
    Oralce 10.2.0
    Windows platform
    I am facing problem of Logical block corruption.
    RMAN validate block corruption (DBVerify as well) But no entry in Alert log file.
    When I check Which segment has block corruption I found that block corruption are in free blocks of tablespace (DBA_FREE_SPACE).
    To Fix it I create table and allocate corrupted block to that table. I confirm corrupted block allocation in table (using DBA_EXTENTS).
    But when I insert rows in that table to reuse corrupted block Oracle give error of ora-1578 Block corruption, and I am not able to reuse corrupted block(as many expert suggest to overcome block corruption in free space).
    I dropped table and recreate and repeat this process many times but still no success.
    So. can anybody help me on this.
    I appreciate your efforts and time you spend to read this
    Thanks

    Hello,
    Please check the link i posted.
    Example: Detecting Corruption
    The CHECK_OBJECT procedure checks the specified object, and populates the repair table with information about corruptions and repair directives. You can optionally specify a range, partition name, or subpartition name when you want to check a portion of an object.
    Validation consists of checking all blocks in the object that have not previously been marked corrupt. For each block, the transaction and data layer portions are checked for self consistency. During CHECK_OBJECT, if a block is encountered that has a corrupt buffer cache header, then that block is skipped.
    The following is an example of executing the CHECK_OBJECT procedure for the scott.dept table.
    SET SERVEROUTPUT ON
    DECLARE num_corrupt INT;
    BEGIN
    num_corrupt := 0;
    DBMS_REPAIR.CHECK_OBJECT (
    SCHEMA_NAME => 'SCOTT',
    OBJECT_NAME => 'DEPT',
    REPAIR_TABLE_NAME => 'REPAIR_TABLE',
    CORRUPT_COUNT => num_corrupt);
    DBMS_OUTPUT.PUT_LINE('number corrupt: ' || TO_CHAR (num_corrupt));
    END;
    SQL*Plus outputs the following line, indicating one corruption:
    number corrupt: 1

  • Block corruption detection in RMAN.

    Hi,
    I'd be be grateful if anyone could confirm or clarify the behaviour of the RMAN backup command with regard to detecting corrupt blocks in the datafiles.
    The environment is as follows:
    10.2.0.5.1
    Solaris 10
    2 node RAC
    Block Change Tracking file is not used.
    DB_BLOCK_CHECKING=OFF
    DB_BLOCK_CHECKSUM=OFF
    Does the BACKUP DATABASE command check both physical and logical block corruptions when run either as a full backup or incremental?
    I'm trying to establish wether running a BACKUP _VALIDATE [CHECK LOGICAL]_* DATABASE on a nightly basis provides any value if the same checks are being performed by the standard backup commands that are already scheduled every night?
    Any input appreciated.
    Thanks

    Hi,
    By default, RMAN just check for physical corruption, either in full or incremental backups. To check logical corruption you have to use the command "backup check logical;".
    About the parameter DB_BLOCK_CHECKSUM, its default is TRUE and Oracle Corporation advises leaving this parameter on default, so that any damage caused while the block is on disk, or corruptions introduced during the write and read process, will be detected.
    Hope it help.
    Regards,

  • Does oracle import datapump fix block corruption?

    Dear all,
    I am having a data block corruption on production. I want to export this DB and import it to a test environment using datapump, in order to do some tests on it.
    However I am concerned whether impdp will resolve this scenario... and therefore I will lose my test case...
    so will oracle import datapump fix block corruption?
    Thank you

    so will oracle import datapump fix block corruption?.No. It detects Logical corruption (corruption and the corrupted segment will not be exported or imported.
    Fix the issue by identifying the segment.
    Get the block information from your alert.log
    select segment_type,owner.segment_name
    from dba_extents
    where file_id = [&file_id] and [&block] between block_id and block_id+blocks -1; if it is index then drop and recreate index
    if it is table and you have backup of that table then restore backup on another database and exp/imp the table.

  • Oracle 10g + VMware Workstation 6.5 = data block corruption?

    I'm trying to run Oracle 10g on VMWare Workstation 6.5 (host and guest are windows 2003)
    I've noticed a couple times that I easily get block corruptions and wonder if there are some settings to lower the risk.
    Note this is a DEV machine, not a production machine.
    I don't know if Oracle supports the set up but I'm sure many people are running Oracle in Vmware so I'm looking to those who have done so successfully.
    Anyone know of special precautions in either Vmware or Oracle config to limit the risk on block corruption?
    According to VMWare, ESX is a perfect platorm so maybe I should move from Workstation to ESX, maybe it has to do with Windows in VM and Linux would work better.
    Anyone has some info on why Oracle has block corruption on VMware Workstation (windows/windows)?
    Other people with positive/negative experience on VMWare Workstation (mention OS's and Oracle version please)
    (before someone tells me it's not supported, also see these pages on vmware.com:
    http://blogs.vmware.com/performance/2007/11/ten-reasons-why.html
    http://blogs.vmware.com/oracle/2009/03/a-perspective-support-for-vmware-with-oracle.html)
    Edited by: phmeert on Feb 26, 2010 4:27 PM

    Well, it's indeed not for production, I use it for product demos and small development tasks, there is no critical data in my database but I wished I could run Oracle inside a VM on my laptop...
    It works reasonably well (I even have run multiple VM's (Workstation) with Oracle insde on 1 laptop (4 GB Ram, Core Duo), but sooner or later it gives some problems. If there is any setting that can lower the risk would be great.
    I was thinking of installing ORacle VM but apparently my laptop is not compatible with that (nor with ESX for that matter).
    Anyone use plain Xen (which seems to support any processor) + Oracle on Linux ??
    I can't install Oracle natively on the machine directly since I need the capabilities of a VM in respect of easy backup + I have many different applications and databases so depending on what I need to show, I just start a different VM
    The VM provides the capabilities to move back to previous situation, exchaning demos with collegues, have multiple parallel copies with different configurations (depending on customer), etc...
    ... installing natively is too much of hassle, we used to swap hard disks but that's a pain when the hardware changes, at least with VMWare WS you can run it on pretty much any computer.
    How do other people deal with this type of situation?? We have ESX on a hosted environment but internet access is not always available...
    It seems stable enough to run my demos (I'm doing this for quite a while but the block corruption seems to happen sooner or later)
    The problem is that I first need to get the demo installed without corruptions. Once it's installed I can just restart from that situation over and over again, but obviously I don't want to run the risk of having a disk corruption in the middle of a demo.

  • Blocks corrupted always with the same checksum 0x400

    Hello Oracle gurus,
    Need your help with finding source of block corruption errors that we observe repeatedly on one system. See the error below.
    Location of the corrupted block is always different, but the computed checksum is always 0x400. Only one block gets corrupted after a couple of days of stress testing. We completely re-install OS (RHEL4) and re-create DB. Still the same error with the same checksome appears, but in a different location. This happened 3 times already.
    Does anybody know what 0x400 corresponds to? Is it all zeroes?
    In my understanding, if the corruption was caused by a drive error, such as a single bit flip or several sectors corruption, then the computed checksum would be always different.
    Is this correct? Any other ideas what can be the reason for such corruption?
    Thanks a lot.
    Hex dump of (file 9, block 357024) in trace file /u01/app/oracle/admin/pndb/udump/pndb_ora_13828.trc
    Corrupt block relative dba: 0x024572a0 (file 9, block 357024)
    Bad check value found during buffer read
    Data in bad block:
    type: 6 format: 2 rdba: 0x024572a0
    last change scn: 0x0000.00b31c70 seq: 0x1 flg: 0x06
    spare1: 0x0 spare2: 0x0 spare3: 0x0
    consistency value in tail: 0x1c700601
    check value in block header: 0xfcd0
    computed block checksum: 0x400
    Reread of rdba: 0x024572a0 (file 9, block 357024) found same corrupted data
    Fri Apr 27 04:09:32 2007
    Corrupt Block Found
    TSN = 9, TSNAME = PN_TABL
    RFN = 9, BLK = 357024, RDBA = 38105760
    OBJN = 40738, OBJD = 40738, OBJECT = PN_EVENT_SESSION_1, SUBOBJECT =
    SEGMENT OWNER = PNADMIN, SEGMENT TYPE = Table Segment

    Well I understand that, however Oracle is running on higher level (application level).
    It's hard to trace a potential lower level ( hardware level) problem in high level application.
    The least thing you can try is find out which object this corrupted block belong if it's always same object or some pattarn you can tell then there might have something to do with Oracle.
    If it's totally random then it's hard to say.
    select segment_name,segment_type,owner
    from sys.dba_extents
    where file_id=(9)
    and (357024) between block_id and block_id + blocks -1;

  • Oracle 11g: Block Corruption in SYSAUX File

    Hello All,
    I am facing Data corruption issue in the SYSAUX file.
    We are using Oracle 11G (Microsoft 32 bit) and our system is running in noarchivelog mode.
    Following are the errors in the alert log.
    e:\sc\sc15.2\databases\oracleconfig\diag\rdbms\enmscsdb\nm45\trace\nm45_p000_5944.trc
    Corrupt block relative dba: 0x0088a9f8 (file 2, block 567800)
    Fractured block found during buffer read
    Data in bad block:
    type: 6 format: 2 rdba: 0x0088a9f8
    last change scn: 0x0000.0b3bb7c7 seq: 0x1 flg: 0x04
    spare1: 0x0 spare2: 0x0 spare3: 0x0
    consistency value in tail: 0xc7000601
    check value in block header: 0xee6b
    computed block checksum: 0x72c6
    Reread of rdba: 0x0088a9f8 (file 2, block 567800) found same corrupted data
    Thu Jan 22 16:46:44 2009
    SMON: Restarting fast_start parallel rollback
    SMON: ignoring slave err,downgrading to serial rollback
    ORACLE Instance nm45 (pid = 12) - Error 1578 encountered while recovering transaction (9, 11) on object 458.
    Errors in file e:\sc\sc15.2\databases\oracleconfig\diag\rdbms\enmscsdb\nm45\trace\nm45_smon_6492.trc:
    ORA-01578: ORACLE data block corrupted (file # 2, block # 567800)
    ORA-01110: data file 2: 'E:\SC\SC15.2\DATABASES\ORACLECONFIG\SYSAUXNM45.ORA'
    Thu Jan 22 16:46:45 2009
    Trace dumping is performing id=[cdmp_20090122164645]
    Corrupt Block Found
    TSN = 1, TSNAME = SYSAUX
    RFN = 2, BLK = 567800, RDBA = 8956408
    OBJN = 458, OBJD = 458, OBJECT = I_WRI$_OPTSTAT_HH_OBJ_ICOL_ST, SUBOBJECT =
    SEGMENT OWNER = SYS, SEGMENT TYPE = Index Segment
    Following query indicates the corruption is in index.
    SQL> SELECT tablespace_name, segment_type, owner, segment_name FROM dba_extents
    WHERE file_id = 2 and 567800 between block_id AND block_id + blocks - 1;
    TABLESPACE_NAME SEGMENT_TYPE OWNER
    SEGMENT_NAME
    SYSAUX INDEX SYS
    I_WRI$_OPTSTAT_HH_OBJ_ICOL_ST
    ==============
    DBverify output:
    ==============
    E:\SC\SC15.2\Databases\OracleConfig>dbv file=SYSAUXNM45.ORA blocksize=8192
    DBVERIFY: Release 11.1.0.7.0 - Production on Thu Jan 22 16:59:11 2009
    Copyright (c) 1982, 2007, Oracle. All rights reserved.
    DBVERIFY - Verification starting : FILE = E:\SC\SC15.2\Databases\OracleConfig/SY
    SAUXNM45.ORA
    DBV-00200: Block, DBA 8956312, already marked corrupt
    Page 567800 is influx - most likely media corrupt
    Corrupt block relative dba: 0x0088a9f8 (file 2, block 567800)
    Fractured block found during dbv:
    Data in bad block:
    type: 6 format: 2 rdba: 0x0088a9f8
    last change scn: 0x0000.0b3bb7c7 seq: 0x1 flg: 0x04
    spare1: 0x0 spare2: 0x0 spare3: 0x0
    consistency value in tail: 0xc7000601
    check value in block header: 0xee6b
    computed block checksum: 0x72c6
    DBVERIFY - Verification complete
    Total Pages Examined : 1623864
    Total Pages Processed (Data) : 540984
    Total Pages Failing (Data) : 0
    Total Pages Processed (Index): 964944
    Total Pages Failing (Index): 0
    Total Pages Processed (Other): 17849
    Total Pages Processed (Seg) : 0
    Total Pages Failing (Seg) : 0
    Total Pages Empty : 100086
    Total Pages Marked Corrupt : 2
    Total Pages Influx : 1
    Total Pages Encrypted : 0
    Highest block SCN : 190789648 (0.190789648)
    SQL> select * from v$database_block_corruption;
    FILE# BLOCK# BLOCKS CORRUPTION_CHANGE# CORRUPTIO
    2 567800 1 0 FRACTURED
    2 567704 1 0 FRACTURED
    How to resolve this issue.
    Thanks
    With Regards
    Hemant Joshi.

    Drop and re-creating the index would be better than re-building the index.
    Check the metalink note: Identify the corruption extension using RMAN/DBV/ANALYZE etc - 836658.1
    Note 28814.1 - Handling Oracle Block Corruptions in Oracle7/8/8i/9i/10g
    Note 472231.1 - How to identify all the Corrupted Objects in the Database reported by RMAN
    ORA-1578 Main Reference Index for Solutions -830997.1

  • Need advice on ORA-01578: ORACLE data block corrupted

    We have a development database server version- 10.2.0.3 with materialized views refresh as complete every morning. Yesterday we had a power failure and the server went down and database was shutdown unexpectedly.
    When we restarted the database after the server restarted, we found some of the datablocks got corrupted . Following were the exceptions that we saw in the alert.log.
    Errors in file /i01_01/app/oracle/product/10.2.0/db_1/admin/orcl9/bdump/orcl9_smon_7547.trc:
    ORA-01578: ORACLE data block corrupted (file # 11, block # 257712)
    ORA-01110: data file 11: '/i01_01/app/oracle/product/10.2.0/oradata/orcl9/ts_gen_data_02.dbf'
    ORACLE Instance orcl9 (pid = 8) - Error 1578 encountered while recovering transaction (9, 38) on object 54463
    I tried the following query to see the segment type.
    select owner, segment_name, segment_type from dba_extents where file_id =11 and 257712 between block_id and block_id + blocks - 1;
    OWNER
    SEGMENT_NAME
    SEGMENT_TYPE
    VISH
    INVENTORY_TXN
    TABLE
    where " INVENTORY_TXN " is a materialized view that was using the block that got corrupted. I can always recreate the MV by dropping and recreating it. Will it solve the problem???
    If not, how can I recover/repair the block.???
    Can anyone advice on this. Thanks very much in advance.

    To recover a corrupted block,the best way out is to use Blockrecover command of RMAN. So you would need RmAN backup to perform the operation.But first ypu you need to ensure that this is a persistent error or not? Is this error is coming repeatedly or just once it happened?
    About Blockrecover command,read here,
    http://download.oracle.com/docs/cd/B19306_01/backup.102/b14191/rcmrecov005.htm#BRADV157
    HTH
    Aman....

  • BLOCK CORRUPTION (ORA-1578) 처리 (ORACLE 8I NEW FEATURE)

    제품 : ORACLE SERVER
    작성날짜 : 2002-05-31
    BLOCK CORRUPTION (ORA-1578) 처리 (ORACLE 8I NEW FEATURE)
    ========================================================
    PURPOSE
    Block Corruption의 처리 방안에 대해 알아본다.
    Problem Description
    block corruption 시 10210, 10211,10231 의 event 를 사용해서
    해당 block 을 skip 할 수도 있지만 V8.1 이상에서는
    dbms_repair.fix_corrupt_blocks ,
    dbms_repair.skip_corrupt_block 를 이용하여
    corrupt가 발생한 block을 detect하고 skip, 또는 repair해주는 방안이
    제시되고 있다.
    Workaround
    Solution Description
    - 먼저 detecting 을 위해 db_block_checking =true 를 init.ora 에 set
    - dbms_repair 의 package 를 사용하는데 이 package 는 dbmsrpr.sql,
    prvtrpr.plb를 수행한다 .
    - sys 로 접속하여 package 를 실행한다.
    다음의 예제를 살펴보자
    T1 테이블에 corrupt 된 block 이 있다고 가정한다.
    SQL> desc t1
    Name Null? Type
    COL1 NOT NULL NUMBER(38)
    COL2 CHAR(512)
    SQL> analyze table t1 validate structure;
    analyze table t1 validate structure
    ERROR at line 1:
    ORA-01498: block check failure - see trace file
    이때 ANALYZE로 부터 발생된 trace file 에 corrupt 된 block 에 3 row 의
    (nrows = 3) data 가 있음을 알수 있다고 가정하자.
    DBMS_REPAIR.ADMIN_TABLES (repair and orphan key)
    ================================================
    ADMIN_TABLES 은 table 을 위한 repair table과,인덱스를 위한 orphan key
    tables을 제공한다.
    SQL> @adminCreate
    SQL> connect sys/change_on_install
    Connected.
    SQL>
    SQL> -- Repair Table
    SQL>
    SQL> declare
    2 begin
    3 -- Create repair table
    4 dbms_repair.admin_tables (
    5 -- table_name => 'REPAIR_TABLE',
    6 table_type => dbms_repair.repair_table,
    7 action => dbms_repair.create_action,
    8 tablespace => 'USERS'); -- default TS of SYS if not specified
    9 end;
    10 /
    PL/SQL procedure successfully completed.
    SQL> select owner, object_name, object_type
    2 from dba_objects
    3 where object_name like '%REPAIR_TABLE';
    OWNER OBJECT_NAME OBJECT_TYPE
    SYS DBA_REPAIR_TABLE VIEW
    SYS REPAIR_TABLE TABLE
    SQL>
    SQL> -- Orphan Key Table
    SQL>
    SQL> declare
    2 begin
    3 -- Create orphan key table
    4 dbms_repair.admin_tables (
    5 table_type => dbms_repair.orphan_table,
    6 action => dbms_repair.create_action,
    7 tablespace => 'USERS'); -- default TS of SYS if not specified
    8 end;
    9 /
    PL/SQL procedure successfully completed.
    SQL> select owner, object_name, object_type
    2 from dba_objects
    3 where object_name like '%ORPHAN_KEY_TABLE';
    OWNER OBJECT_NAME OBJECT_TYPE
    SYS DBA_ORPHAN_KEY_TABLE VIEW
    SYS ORPHAN_KEY_TABLE TABLE
    DBMS_REPAIR.CHECK_OBJECT
    =========================
    CHECK_OBJECT procedure 는 기술된 object를 check 하고, repair 를 위한 정보를 수집하기 위함이다.
    SQL> @checkObject
    SQL> set serveroutput on
    SQL>
    SQL> declare
    2 rpr_count int;
    3 begin
    4 rpr_count := 0;
    5 dbms_repair.check_object (
    6 schema_name => 'SYSTEM',
    7 object_name => 'T1',
    8 repair_table_name => 'REPAIR_TABLE',
    9 corrupt_count => rpr_count);
    10 dbms_output.put_line('repair count: ' || to_char(rpr_count));
    11 end;
    12 /
    repair count: 1
    PL/SQL procedure successfully completed.
    SQL> desc repair_table
    Name Null? Type
    OBJECT_ID NOT NULL NUMBER
    TABLESPACE_ID NOT NULL NUMBER
    RELATIVE_FILE_ID NOT NULL NUMBER
    BLOCK_ID NOT NULL NUMBER
    CORRUPT_TYPE NOT NULL NUMBER
    SCHEMA_NAME NOT NULL VARCHAR2(30)
    OBJECT_NAME NOT NULL VARCHAR2(30)
    BASEOBJECT_NAME VARCHAR2(30)
    PARTITION_NAME VARCHAR2(30)
    CORRUPT_DESCRIPTION VARCHAR2(2000)
    REPAIR_DESCRIPTION VARCHAR2(200)
    MARKED_CORRUPT NOT NULL VARCHAR2(10)
    CHECK_TIMESTAMP NOT NULL DATE
    FIX_TIMESTAMP DATE
    REFORMAT_TIMESTAMP DATE
    SQL> select object_name, block_id, corrupt_type, marked_corrupt,
    2 corrupt_description, repair_description
    3 from repair_table;
    OBJECT_NAME BLOCK_ID CORRUPT_TYPE MARKED_COR
    CORRUPT_DESCRIPTION
    REPAIR_DESCRIPTION
    T1 3 1 FALSE
    kdbchk: row locked by non-existent transaction
    table=0 slot=0
    lockid=32 ktbbhitc=1
    mark block software corrupt
    Data Extraction
    ===============
    repair table에 의하면 file 6 ,block 3 에 corrupt 이 났음을 알수 있다
    그러나 아직 이 block 은 corrupt 로 mark 되어 있지 않으므로 필요 data 를
    추출하여야 한다.
    1. ALTER SYSTEM DUMP (nrows = 3) 에 의해 block안에 있는 row수를 결정한다.
    2. corrupt object를 select 하여 가능한 정보를 추출한다.
    SQL> -- The following query can be used to salvage data from a corrupt block.
    SQL> -- Creating a temporary table facilitates data insertion.
    SQL> create table temp_t1 as
    2 select * from system.t1
    3 where dbms_rowid.rowid_block_number(rowid) = 3
    4 and dbms_rowid.rowid_to_absolute_fno (rowid, 'SYSTEM','T1') = 6;
    Table created.
    SQL> select col1 from temp_t1;
    COL1
    2
    3
    DBMS_REPAIR.FIX_CORRUPT_BLOCKS (ORA-1578)
    ============================================
    FIX_CORRUPT_BLOCKS procedure는 repair table 의 정보를 이용하여 corrupt
    blocks 을 fix 한다
    그러나 아직 full table scan 시 여전히 error 가 발생한다
    SQL> declare
    2 fix_count int;
    3 begin
    4 fix_count := 0;
    5 dbms_repair.fix_corrupt_blocks (
    6 schema_name => 'SYSTEM',
    7 object_name => 'T1',
    8 object_type => dbms_repair.table_object,
    9 repair_table_name => 'REPAIR_TABLE',
    10 fix_count => fix_count);
    11 dbms_output.put_line('fix count: ' || to_char(fix_count));
    12 end;
    13 /
    fix count: 1
    PL/SQL procedure successfully completed.
    SQL> select object_name, block_id, marked_corrupt
    2 from repair_table;
    OBJECT_NAME BLOCK_ID MARKED_COR
    T1 3 TRUE
    SQL> select * from system.t1;
    select * from system.t1
    ERROR at line 1:
    ORA-01578: ORACLE data block corrupted (file # 6, block # 3)
    ORA-01110: data file 6: '/tmp/ts_corrupt.dbf'
    DBMS_REPAIR.DUMP_ORPHAN_KEYS
    ==============================
    DUMP_ORPHAN_KEYS는 corrupt data 에 해당하는 index 를 나타내 준다
    SQL> select index_name from dba_indexes
    2 where table_name in (select distinct object_name from repair_table);
    INDEX_NAME
    T1_PK
    SQL> @dumpOrphanKeys
    SQL> set serveroutput on
    SQL>
    SQL> declare
    2 key_count int;
    3 begin
    4 key_count := 0;
    5 dbms_repair.dump_orphan_keys (
    6 schema_name => 'SYSTEM',
    7 object_name => 'T1_PK',
    8 object_type => dbms_repair.index_object,
    9 repair_table_name => 'REPAIR_TABLE',
    10 orphan_table_name => 'ORPHAN_KEY_TABLE',
    11 key_count => key_count);
    12 dbms_output.put_line('orphan key count: ' || to_char(key_count));
    13 end;
    14 /
    orphan key count: 3
    PL/SQL procedure successfully completed.
    SQL> desc orphan_key_table
    Name Null? Type
    SCHEMA_NAME NOT NULL VARCHAR2(30)
    INDEX_NAME NOT NULL VARCHAR2(30)
    IPART_NAME VARCHAR2(30)
    INDEX_ID NOT NULL NUMBER
    TABLE_NAME NOT NULL VARCHAR2(30)
    PART_NAME VARCHAR2(30)
    TABLE_ID NOT NULL NUMBER
    KEYROWID NOT NULL ROWID
    KEY NOT NULL ROWID
    DUMP_TIMESTAMP NOT NULL DATE
    SQL> select index_name, count(*) from orphan_key_table
    2 group by index_name;
    INDEX_NAME COUNT(*)
    T1_PK 3
    Note: orphan key table의 index 는 다시 rebuild 되어야 한다.
    DBMS_REPAIR.SKIP_CORRUPT_BLOCKS
    ===============================
    SKIP_CORRUPT_BLOCKS 은 table 과 index 의 corrupt block 을 skip 하는 것을 enable/disable 을 실시한다.
    Suggestion: SKIP_CORRUPT_BLOCKS 가 enabled되면 orphan key table의 모든
    index 는 모두 rebuild 되어야 한다. ( all index associated with object
    if DUMP_ORPHAN_KEYS was omitted).
    SQL> @skipCorruptBlocks
    SQL> declare
    2 begin
    3 dbms_repair.skip_corrupt_blocks (
    4 schema_name => 'SYSTEM',
    5 object_name => 'T1',
    6 object_type => dbms_repair.table_object,
    7 flags => dbms_repair.skip_flag);
    8 end;
    9 /
    PL/SQL procedure successfully completed.
    SQL> select table_name, skip_corrupt from dba_tables
    2 where table_name = 'T1';
    TABLE_NAME SKIP_COR
    T1 ENABLED
    SQL> -- rows in corrupt block skipped, no errors on full table scan
    SQL> select * from system.t1;
    COL1 COL2
    4 dddd
    5 eeee
    --> Notice the pk index has not yet been corrected.
    SQL> insert into system.t1 values (1,'aaaa');
    insert into system.t1 values (1,'aaaa')
    SQL> select * from system.t1 where col1 = 1;
    no rows selected
    DBMS_REPAIR.REBUILD_FREELISTS
    ===============================
    REBUILD_FREELISTS rebuilds freelists for the specified object.
    SQL> declare
    2 begin
    3 dbms_repair.rebuild_freelists (
    4 schema_name => 'SYSTEM',
    5 object_name => 'T1',
    6 object_type => dbms_repair.table_object);
    7 end;
    8 /
    PL/SQL procedure successfully completed.
    Rebuild Index
    =============
    Note: Every index identified in the orphan key table should be rebuilt to
    ensure consistent results.
    SQL> alter index system.t1_pk rebuild online;
    Index altered.
    SQL> insert into system.t1 values (1, 'aaaa');
    1 row created.
    SQL> select * from system.t1;
    COL1 COL2
    4 dddd
    5 eeee
    1 aaaa
    Reference Document
    ------------------

    Try look to alert<SID>.log file for full error report (you could paste it here).
    Also from alert log you could get real values for db_block_buffers and shared_pool_size parameters that used during instance startup.

  • Diff between logical and physical block corruption

    What is the difference between Physical and Logical block corruption.
    Dbverify utility, analyze command is used to check the logical block corruption not the physical one am i correct??
    When i get
    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'
    How to conform that this a logical or physical block corruption???
    please through some light regarding this....
    kumaresh

    the following link may help u
    http://download-east.oracle.com/docs/cd/B19306_01/backup.102/b14191/rcmconc1012.htm

  • System datafile block corruption - no backups and database in NOARCHIVELOG mode

    Dear All,
    Database version - oracle 11.1 Enterprise
    OS - RHELinux 5.8
    What are the options of recovering from physical block corruption when there are no backup available to perform block media recovery?
    V$DATABASE_BLOCK_CORRUPTION reports two segments corrupted (please see attached image for details).
    1 table in system datafile - sys_fba_barrierscn
    1 index - (applicaiton index)
    What are my options?
    I know there is a possibility that the database will not restart after a shutdown due to corruption in system tablespace.
    Database is in noarchivelog mode. So online backups are not possible and there aren't any full backups either.
    I am thinking of below,
    1. Run dbms_repair with fix_block_corruption. - Still database startup might fail?
    2. Shutdown the database and take offline full backup with RMAN MAXCorrupt option.
    Appreciate your suggestions and advises.
    Thanks
    Stefan

    Thanks Sybrand,
    Agree with your first two suggestions .
    Also scheduled a expdp job tonight. (Only backup like thing they had was a expdp cron, but until today all the large tables were failing due to small undo_retention).
    Yes. Flashback is not used. So hopefully it will not affect the a database restart i guess?
    Related to dbms_repair, I was referring to - http://askdba.org/weblog/2010/08/physical-corruption-ora-1578-part-3/.
    Where DBMS_REPAIR.FIX_CORRUPT_BLOCKS and DBMS_REPAIR.SKIP_CORRUPT_BLOCKS used.
    Which i think will not use any redo.
    Thanks
    Stefan

  • Oracle 11g - How to repair block corruption(on free space) in datafile

    Hi,
    I have a tablesopace with 3 datafiles, out of which one datafile has corrupted block. But no objects or data is affected as the corrupted block os in free space. This was shown in the alert logs.
    Please see below the details:
    Wed Apr 06 15:30:04 2011
    SMON: Restarting fast_start parallel rollback
    SMON: ignoring slave err,downgrading to serial rollback
    ORACLE Instance geooap (pid = 12) - Error 1578 encountered while recovering transaction (10, 6) on object 149755.
    Errors in file f:\oracle11g\diag\rdbms\geooap\geooap\trace\geooap_smon_5540.trc:
    ORA-01578: ORACLE data block corrupted (file # 7, block # 54053)
    ORA-01110: data file 7: 'F:\ORACLE11G\ORADATA\GEOOAP\ORDER_DATA_01.DBF'
    GEOAP:
    Fri Apr 01 14:57:48 2011
    Errors in file f:\oracle11g\diag\rdbms\geop\geop\trace\geop_arc1_2156.trc:
    ORA-00235: control file read without a lock inconsistent due to concurrent update
    Fri Apr 01 14:57:58 2011
    ================================================================
    The corruption is being reported in a free space block of the ORDER_DATA_01.DBF.
    I’ve checked all the tables (and indexes) in this tablespace and none report corruption.
    =====================================================Is there any action I need to take to remove corruption at this point?It is not affected any operation on the database yet.
    What is the best way to do get rid of the corrupt block, without dropping and rebuillding the full tablespace(which is around 6 GB -total of 3 datafiles)
    Thanks a lot

    Can RMAN recover the datablock from this cold backup(which is a week old, the data file was not corrupted then) ?Please note that to do the recovery, you would need the backup and the archivelog files since the backup. Think about what you are asking to do. Its a single block whose recovery you are asking from a week old backup which obviously would be on an much older SCN compared to the rest of the database. How would you make that block consistent with the rest of the datafile. If you don't have archivelog in that db whose block is corrupted, you may forget that block and any data that it might ever had. Also, please read the documentation about the block recovery which explains the requirements very clearly,
    http://download.oracle.com/docs/cd/E11882_01/backup.112/e10642/rcmblock.htm#BRADV89784
    From the above link, 1st point,
    The target database must run in ARCHIVELOG mode and be open or mounted with a current control file.HTH
    Aman....

Maybe you are looking for