Help on block corruption (URGENT ...!)

Hi all.
I have a Oracle 10g Rel1 database on a linux box who is presenting block corruption at the system tablespace level.
This database IS NOT in archive mode.
Message says:
ORA-01578: bloque de datos ORACLE corrupto (archivo numero 1, bloque numero *47132*)
ORA-01110: archivo de datos *1: '/u01/oradata/BADAN1/BADAN1/system01.dbf'*
This script is suppose to tell me which is the segment holding corrupted block:
SQL> SELECT e.file_id,
2 e.block_id,
3 e.owner,
4 e.segment_name,
5 e.segment_type
6 FROM dba_extents e
7 WHERE
8 file_id=1 and 47132 BETWEEN 47132 AND 47132 + blocks - 1
9 /
FROM dba_extents e
ERROR at line 6:
ORA-01578: ORACLE data block corrupted (file # 1, block # 47132)
ORA-01110: data file 1: '/u01/oradata/BADAN1/BADAN1/system01.dbf'
It seems base tables associated with dba_extents view are related in this case:
select ds.owner, ds.segment_name, ds.partition_name, ds.segment_type,
ds.tablespace_name,
e.ext#, f.file#, e.block#, e.length * ds.blocksize, e.length, e.file#
from sys.uet$ e, sys.sys_dba_segs ds, sys.file$ f
where e.segfile# = ds.relative_fno
and e.segblock# = ds.header_block
and e.ts# = ds.tablespace_id
and e.ts# = f.ts#
and e.file# = f.relfile#
and bitand(NVL(ds.segment_flags,0), 1) = 0
and bitand(NVL(ds.segment_flags,0), 65536) = 0
union all
select /*+ ordered use_nl(e) use_nl(f) */
ds.owner, ds.segment_name, ds.partition_name, ds.segment_type,
ds.tablespace_name,
e.ktfbueextno, f.file#, e.ktfbuebno,
e.ktfbueblks * ds.blocksize, e.ktfbueblks, e.ktfbuefno
from sys.sys_dba_segs ds, sys.x$ktfbue e, sys.file$ f
where e.ktfbuesegfno = ds.relative_fno
and e.ktfbuesegbno = ds.header_block
and e.ktfbuesegtsn = ds.tablespace_id
and e.ktfbuesegtsn = f.ts#
and e.ktfbuefno = f.relfile#
and bitand(NVL(ds.segment_flags, 0), 1) = 1
and bitand(NVL(ds.segment_flags,0), 65536) = 0
Please anybody advise on what to do ...!
Regards, Luis ...!

myluism wrote:
Hi all.
I have a Oracle 10g Rel1 database on a linux box who is presenting block corruption at the system tablespace level.
This database IS NOT in archive mode.
Message says:
ORA-01578: bloque de datos ORACLE corrupto (archivo numero 1, bloque numero *47132*)
ORA-01110: archivo de datos *1: '/u01/oradata/BADAN1/BADAN1/system01.dbf'*
This script is suppose to tell me which is the segment holding corrupted block:
SQL> SELECT e.file_id,
2 e.block_id,
3 e.owner,
4 e.segment_name,
5 e.segment_type
6 FROM dba_extents e
7 WHERE
8 file_id=1 and 47132 BETWEEN 47132 AND 47132 + blocks - 1
9 /
FROM dba_extents e
ERROR at line 6:
ORA-01578: ORACLE data block corrupted (file # 1, block # 47132)
ORA-01110: data file 1: '/u01/oradata/BADAN1/BADAN1/system01.dbf'That query doesn't look right to me. Try this:
SELECT e.file_id,
e.block_id,
e.owner,
e.segment_name,
e.segment_type
FROM dba_extents e
WHERE
file_id=1  and 47132 BETWEEN block_id  AND block_id + blocks - 1
/Let us know the result of that query.
-Mark

Similar Messages

  • Needs help regarding block corruption

    DB Version - 11.2.0.3.0
    Issue - Last backup failed due to block corruption ,message says "ORA-19566: exceeded limit of 0 corrupt blocks for file /GP/GAA01-N-P/db00/index01/GPEDWPR/bi_gpedw_fcct.dbf'
    I tried to perform block recovery using RMAN but it was not present in backup, hence failed. tried in the below way also :-
    RMAN> LIST FAILURE
    2> ;
    using target database control file instead of recovery catalog
    List of Database Failures
    =========================
    Failure ID Priority Status Time Detected Summary
    72981 HIGH OPEN 13-JAN-13 Datafile 58: '/GP/GAA01-N-P/db00/index01/GPEDWPR/bi_gpedw_fcct.dbf'
    contains one or more corrupt blocks
    RMAN> ADVISE FAILURE
    2> ;
    List of Database Failures
    =========================
    Failure ID Priority Status Time Detected Summary
    72981 HIGH OPEN 13-JAN-13 Datafile 58: '/GP/GAA01-N-P/db00/index01/GPEDWPR/bi_gpedw_fcct..dbf' contains one or more corrupt blocks
    analyzing automatic repair options; this may take some time
    allocated channel: ORA_DISK_1
    channel ORA_DISK_1: SID=2055 device type=DISK
    analyzing automatic repair options complete
    Mandatory Manual Actions
    ========================
    1. No backup of block 3106752 in file 58 was found. Drop and re-create the associated object (if possible), or use the DBMS_REPAIR package to repair the block corruption
    2. No backup of block 3106911 in file 58 was found. Drop and re-create the associated object (if possible), or use the DBMS_REPAIR package to repair the block corruption
    3. No backup of block 3106976 in file 58 was found. Drop and re-create the associated object (if possible), or use the DBMS_REPAIR package to repair the block corruption
    4. No backup of block 3107504 in file 58 was found. Drop and re-create the associated object (if possible), or use the DBMS_REPAIR package to repair the block corruption
    5. Contact Oracle Support Services if the preceding recommendations cannot be used, or if they do not fix the failures selected for repair
    Now how to troubleshoot ? Any help will be highly appreciated

    First, you need to determine to which segment the block is assigned:
    select segment_type,owner,segment_name
    from dba_extents
    where file_id=58 and 3106752 between block_id and (blockid + blocks -1);
    Your action from there will depend on the type of segment. Since you have no backup, the options are limited. But there are still possibilities.

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

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

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

  • 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

  • Finding and fixing block corruption in oracle 10g

    10.2.0.5.6
    OS: Hp-unix
    databases files on RAW.
    DB Size: 10 TBs+
    We had a SAN outage recently. The DB is back online. We want to check for block corruption to be on the safe side. We are planning to take a SAN EMC BCV copy of prod to run this. Looking for opinioms on the best way.Production is up and running. This is just a sanity check.
    We are NOT using RMAN for backups. We do a BCV copy and then back that up and archive logs to tape.
    RMAN: Can we do this from the control files? Do we have to set anything up? Is this the best way?
    DBMS_REPAIR: I have not used this. We don't even have the package installed. I can install it.
    DB_VERIFY: not sure if this is a good option or not. Is this current? I know I'll have to do it file by file and grep the logs. I have used this in the past, but its been a while.
    Performance issues, CPU, I/O don't matter. We are doing a BCV copy and then mounting the DB on a new server.

    Guess2 wrote:
    10.2.0.5.6
    OS: Hp-unix
    databases files on RAW.
    DB Size: 10 TBs+
    We had a SAN outage recently. The DB is back online. We want to check for block corruption to be on the safe side. We are planning to take a SAN EMC BCV copy of prod to run this. Looking for opinioms on the best way.Production is up and running. This is just a sanity check.
    We are NOT using RMAN for backups. We do a BCV copy and then back that up and archive logs to tape.
    RMAN: Can we do this from the control files? Do we have to set anything up? Is this the best way?
    DBMS_REPAIR: I have not used this. We don't even have the package installed. I can install it.
    DB_VERIFY: not sure if this is a good option or not. Is this current? I know I'll have to do it file by file and grep the logs. I have used this in the past, but its been a while.
    Performance issues, CPU, I/O don't matter. We are doing a BCV copy and then mounting the DB on a new server.
    bcm@bcm-laptop:~$ dbv -help
    DBVERIFY: Release 11.2.0.1.0 - Production on Mon May 21 07:29:42 2012
    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)           can be done against any datafile; open or closed, production or clone
    Handle:     Guess2
    Status Level:     Newbie
    Registered:     Aug 5, 2000
    Total Posts:     454
    Total Questions:     212 (201 unresolved)
    WHY so MANY unanswered questions?
    Edited by: sb92075 on May 21, 2012 7:31 AM

  • (oracle) block corruption

    Hi Everybody,
    Recently, my site has a development database that encountered block corruption in the system tablespace. I have verified this by using Oracle utility DBVERIFY on the system datafile.
    We have no backup at all for this development database. So database recovery from backup is impossible for us.
    I understand that there's a package called DBMS_REPAIR that can be used to repair corrupted blocks. I tried using this, but the process failed because it could not access the system tablespace (which is corrupted) to create a table used by the package.
    Does anyone know if I could overcome this problem and repair the corrupted blocks on the system tablespace?
    Also, I would like to understand what are the possible causes of block corruption. My site's Oracle Server and databases are installed on Windows 2000 platform.
    Please help answer my queries if you can. Thank you!
    null

    Iam sorry that I have not seen this posting until today .
    When there is a block corruption export will fail with error.
    The best method is to replace this file with a backup file and roll forward.
    null

  • How to check & resolve block corruption if no RMAN backup is there?

    *<<+MY Findings+>>*
    to check block corruption :
    (run command)
    select * from v$database_block_corruption;
    DB_VERIFY is useful in these situations:
    When block corruption is expected;
    Forecast any future problems w.r.t. database file/ block corruption;
    When you restore files from a tape. It will help knowing if the first file pulled from tape is corrupt, instead of spending hours to extract all of them.
    to check block corruption
    DBVerify
    C:\>dbv userid=nfadmin/nfadmin file=+DG1/nfdb/datafile/low_s_data.304.782536883 feedback=10000 blocksize=8192
    can use DBMS_REPAIR to detect and repair corrupt blocks in tables and indexes
    BEGIN
    DBMS_REPAIR.admin_tables (
    table_name => 'REPAIR_TABLE',
    table_type => DBMS_REPAIR.repair_table,
    action => DBMS_REPAIR.create_action,
    tablespace => 'USERS');
    DBMS_REPAIR.admin_tables (
    table_name => 'ORPHAN_KEY_TABLE',
    table_type => DBMS_REPAIR.orphan_table,
    action => DBMS_REPAIR.create_action,
    tablespace => 'USERS');
    END;
    Question* :::how to check & resolve block corruption if no RMAN backup is there?

    http://www.oracle.com/technetwork/database/focus-areas/availability/maa-datacorruption-bestpractices-396464.pdf
    http://www.oracle-base.com/articles/misc/detect-and-correct-corruption.php

  • Database Block Corruption

    Dear Experts,
    In our BW system, from the alert log we have found that one oracle block was corrupted.
    > ORA-01578: ORACLE data block corrupted (file # 137, block #
    > 516877)#ORA-01110: data file 137:
    > '/oracle/PBP/sapdata1/sr3_121/sr3.data121'#ORA-26040: Data
    > block was loaded using the NOLOGGING option
    Database error 1578
    Database error 1578 at FET
    > ORA-01578: ORACLE data block corrupted (file # 137, block #
    > 516877)#ORA-01110: data file 137:
    > '/oracle/PBP/sapdata1/sr3_121/sr3.data121'#ORA-26040: Data
    > block was loaded using the NOLOGGING option
    Database error 1578
    From the SAP Market place we have found one KBA (1812719 - Avoid NOLOGGING during the index creation) which says that it was not really a corruption and it can be cleared by rebuilding the index.
    Can any one please help us how to find the index present in that block. I have tried with below command which returns no rows.
    SQL> select segment_name, partition_name, segment_type, block_id, blocks from dba_extents where (516877 between block_id and (block_id + blocks - 1)) and file_id = 137 and rownum < 2;
    no rows selected
    SQL>
    Please suggest how to find the index for rebuilding the same for clearing the corruption.
    Thanks
    Suresh

    Hi Suresh,
    Kindly check SAP Notes  365481 - Block corruptions
    1559652 - How to deal with block corruptions on Oracle
    923919 - Advanced Oracle block checking features
    Regards,
    Gaurav

  • System and sysaux file block corruption

    Errors in file /u01/app/oracle/diag/rdbms/pdent/pdent/trace/pdent_smon_3135.trc:
    ORA-00604: error occurred at recursive SQL level 1
    ORA-01578: ORACLE data block corrupted (file # 1, block # 91607)
    ORA-01110: data file 1: '/u01/app/oracle/oradata/pdent/system01.dbf'
    I am unable to take r man backup, as well as export using datapump. i tried to recover it using rman blockrecover but still same. here is detail
    SQL> SELECT * FROM V$DATABASE_BLOCK_CORRUPTION;
    FILE# BLOCK# BLOCKS CORRUPTION_CHANGE# CORRUPTIO
    1 91607 1 0 CHECKSUM
    2 58710 1 0 CHECKSUM
    5 1202316 1 0 CHECKSUM
    SQL> SELECT
    tablespace_name,
    segment_type,
    owner,
    segment_name
    FROM dba_extents
    WHERE file_id = 1
    AND BETWEEN block_id AND block_id + blocks - 1; 2 3 4 5 6 7 8
    TABLESPACE_NAME SEGMENT_TYPE OWNER
    SEGMENT_NAME
    SYSTEM INDEX SYS
    I_OBJ2
    alter system dump datafile 1 block 344;
    SQL> SELECT
    tablespace_name,
    segment_type,
    owner,
    segment_name
    FROM dba_extents
    WHERE file_id = 2
    AND 58710 BETWEEN block_id AND block_id + blocks - 1; 2 3 4 5 6 7 8
    TABLESPACE_NAME SEGMENT_TYPE OWNER
    SEGMENT_NAME
    SYSAUX INDEX PARTITION SYS
    WRH$_OSSTAT_PK
    SQL> ALTER INDEX I_OBJ2 REBUILD ONLINE;
    ALTER INDEX I_OBJ2 REBUILD ONLINE
    ERROR at line 1:
    ORA-00701: object necessary for warmstarting database cannot be altered
    need immediate help.
    thanks in advance

    user11914238 wrote:
    Errors in file /u01/app/oracle/diag/rdbms/pdent/pdent/trace/pdent_smon_3135.trc:
    ORA-00604: error occurred at recursive SQL level 1
    ORA-01578: ORACLE data block corrupted (file # 1, block # 91607)
    ORA-01110: data file 1: '/u01/app/oracle/oradata/pdent/system01.dbf'
    I am unable to take r man backup, as well as export using datapump. i tried to recover it using rman blockrecover but still same. here is detail
    SQL> SELECT * FROM V$DATABASE_BLOCK_CORRUPTION;
    FILE# BLOCK# BLOCKS CORRUPTION_CHANGE# CORRUPTIO
    1 91607 1 0 CHECKSUM
    2 58710 1 0 CHECKSUM
    5 1202316 1 0 CHECKSUM
    SQL> SELECT
    tablespace_name,
    segment_type,
    owner,
    segment_name
    FROM dba_extents
    WHERE file_id = 1
    AND BETWEEN block_id AND block_id + blocks - 1; 2 3 4 5 6 7 8
    TABLESPACE_NAME SEGMENT_TYPE OWNER
    SEGMENT_NAME
    SYSTEM INDEX SYS
    I_OBJ2
    alter system dump datafile 1 block 344;
    SQL> SELECT
    tablespace_name,
    segment_type,
    owner,
    segment_name
    FROM dba_extents
    WHERE file_id = 2
    AND 58710 BETWEEN block_id AND block_id + blocks - 1; 2 3 4 5 6 7 8
    TABLESPACE_NAME SEGMENT_TYPE OWNER
    SEGMENT_NAME
    SYSAUX INDEX PARTITION SYS
    WRH$_OSSTAT_PK
    SQL> ALTER INDEX I_OBJ2 REBUILD ONLINE;
    ALTER INDEX I_OBJ2 REBUILD ONLINE
    ERROR at line 1:
    ORA-00701: object necessary for warmstarting database cannot be altered
    need immediate help.
    Immediate help can be only provided by Oracle Support Services. So if you need that, please raise a Sev1 SR . For your issue, as others have suggested already, if you have a valid backup and you are in the archive log mode, using RMAN's BMR(Block Media Recovery) , the issue can be resolved provided there is nothing wrong with the hardware of yours. If that's the case, recovery wouldn't yield any benefits.
    Aman....

  • Block corruption problem in alert and rman/dbv no show errors

    Hello, I'm new in Oracle's world. I have one problem with Oracle 10.2.0.4 (RHEL 5.6) x64. Archive redo-log enable
    In the alert.log, three days ago show (the server have kernel panic & rebooted):
    Mon Sep 24 18:18:17 2012
    Hex dump of (file 17, block 669888) in trace file xxxxxxxxxx.trc
    Corrupt block relative dba: 0x044a38c0 (file 17, block 669888)
    Bad check value found during buffer read
    Data in bad block:
    type: 6 format: 2 rdba: 0x044a38c0
    last change scn: 0x0000.14eb5309 seq: 0x1 flg: 0x04
    spare1: 0x0 spare2: 0x0 spare3: 0x0
    consistency value in tail: 0x53090601
    check value in block header: 0x6ea3
    computed block checksum: 0x2
    Reread of rdba: 0x044a38c0 (file 17, block 669888) found same corrupted data
    Mon Sep 24 18:18:19 2012
    Corrupt Block Found
    TSN = 23, TSNAME = TABLE_TSD1
    RFN = 17, BLK = 669888, RDBA = 71973056
    OBJN = 86908, OBJD = 86908, OBJECT = SYS_C0040110, SUBOBJECT =
    SEGMENT OWNER = SCHEMA1, SEGMENT TYPE = Index Segment
    Yesterday, we detected this error because SQL don't execute.
    The error repeat 47times and there is 6 different file-block combination (4 index of schemas, 1 of sys and ¡2 tables!)
    First, I launched expdp and exp of the one problematic schema. The export was fine, no errors while exporting, but in the alert.log show one block corruption. Should exp and expd show error and stop?
    Next, I used dbv and verify all dbfs. Only show 2 blocks error in two datafiles (indexes).
    Next, I used RMAN:
    A) check database: no error.
    B) validate database: error in two blocks (logical error) and different from the 6 in alert.log. This two blocks are indexes.
    I re-create this two indexes. When i re-create, the block error disappear (not inmediate, suppose that disappear when block was rewrite). Now dbv and rman show no error.
    I have read one note about types of error, other about procedures if db is in archivelog/noarchivelog. Also if object is index or table. But I find anything about auto-repair corrupt blocks in Oracle or why now the 6 block error are solved. I don't know if two tables with two block corrupt lost rows or not.
    Appreciate any help.
    Regards

    Hello Fran. Result of query before rebuild problematic INDEXES:
    SQL> select * from V$database_block_corruption;
    FILE# BLOCK# BLOCKS CORRUPTION_CHANGE# CORRUPTIO
    3 98857 1 390928740 LOGICAL
    9 48632 1 390325900 LOGICAL
    When I ran RMAN first time to check blocks, it filled V$database_block_corruption with two bad blocks. Different from the 6 errors from alert.:
    RMAN> backup validate check logical database;
    Error backing up file 9, block 48632: logical corruption
    Error backing up file 3, block 98857: logical corruption
    I extracted index name from each block and I re-created it. Also, I created a temporary table in tablespace's datafile to fill blocks empty. Problem solved. Rman / dbv show no error.
    I'm searching for similar experiences and found: Re: Data in bad block
    First 6 bad checksum errors in alert.log disappear with any visible problem?
    Can I sure that DB is fine if RMAN and DBV show no errors?
    Thank you very much
    Edited by: user7755509 on 27-sep-2012 5:43

  • 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 In Free Space Chuck Of A Datafile

    Hi all,
    I have run into this issue where both dbv and rman have caught a block corruption on one of the datafiles. When I checked these blocks, they did not belong to any segments and I was able to verify that this block ID falls in the block_id + blocks range in the dba_free_space where file_id = 41.
    My questions are ...
    - why is rman complaining about a bad block in free space? It will never need to back it up any way?
    - According to note 28814.1, this type of corruption can be ignored and if when oracle needs to use this block, it will simply create/rewrite a new image without the corrupted data. Have you been affected by this issue? If yes, what did you do?
    Thank you

    1. "why is rman complaining about a bad block in free space? It will never need to back it up any way?"
    Because it is doing its job.
    2. "Have you been affected by this issue? If yes, what did you do?"
    In what version? I generally find it helpful to read the docs and check discussions of issues on metalink.

  • Block corruption

    Hi,
    I used DBV utility to check block corruption in each datafile and it returned no corrupt block. So for redolog files i used the same utility and it given a long list of info which i can't rectify what that means? there is block corruption in redolog files or this something else.
    DBVERIFY - Verification starting : FILE = /oracle/BP3/origlogA-New/log_g1m1.log
    Page 1 is influx - most likely media corrupt
    Corrupt block relative dba: 0x00000001 (file 0, block 1)
    Fractured block found during dbv:
    Data in bad block:
    type: 1 format: 2 rdba: 0x00000001
    last change scn: 0x8000.0002b7af seq: 0x5e flg: 0xbd
    spare1: 0x0 spare2: 0x0 spare3: 0x0
    consistency value in tail: 0x00000000
    check value in block header: 0x0
    computed block checksum: 0x0
    Page 2 is marked corrupt
    Corrupt block relative dba: 0x00000002 (file 0, block 2)
    Bad header found during dbv:
    Data in bad block:
    type: 1 format: 2 rdba: 0x00000002
    last change scn: 0x8010.0002b7af seq: 0x98 flg: 0x7e
    spare1: 0x0 spare2: 0x0 spare3: 0x70
    consistency value in tail: 0x00030003
    check value in block header: 0x0
    computed block checksum: 0x0
    Page 3 is marked corrupt
    Corrupt block relative dba: 0x00000003 (file 0, block 3)
    Bad header found during dbv:
    Data in bad block:
    type: 1 format: 2 rdba: 0x00000003
    last change scn: 0x8010.0002b7af seq: 0x4d flg: 0x21
    spare1: 0x0 spare2: 0x0 spare3: 0x3f8
    consistency value in tail: 0x41ffffff
    check value in block header: 0x0
    block checksum disabled
    and goes on
    Thanks and Regards
    Jafar

    Hi,
    DB Verify
    DB_VERIFY (dbv) is a utility than can be used to perform a physical structure integrity check against off-line database files.
    This utility runs perfectly well against on-line files as well, however, the manual is clear that it is an off-line utility. My assumption is that it may incorrectly report blocks as bad while I/O is taken place (fractured blocks).
    DBA 's should use this utility frequently to identify datafiles that are corrupted. Some times the database will perform normally until you address a particular block in the datafile, which may then result in ORA-600 errors.
    DB_VERIFY is useful in these situations:
    When block corruption is expected;
    Forecast any future problems w.r.t. database file/ block corruption;
    When you restore files from a tape. It will help knowing if the first file pulled from tape is corrupt, instead of spending hours to extract all of them.
    To access help on DB_VERIFY type:
    DSS-BWDB:orabp3 2% dbv help=y
    DBVERIFY: Release 10.2.0.2.0 - Production on Fri Feb 8 15:52:02 2008
    Copyright (c) 1982, 2005, Oracle. 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)
    EXAMPLE
    $ dbv file=/u01/oradata/o10gr2/example01.dbf
    DBVERIFY: Release 10.2.0.1.0 - Production on Sat Jul 7 11:45:52 2007
    Copyright (c) 1982, 2005, Oracle. All rights reserved.
    DBVERIFY - Verification starting : FILE = /u01/oradata/o10gr2/example01.dbf
    DBVERIFY - Verification complete
    Total Pages Examined : 12800
    Total Pages Processed (Data) : 4409
    Total Pages Failing (Data) : 0
    Total Pages Processed (Index): 1264
    Total Pages Failing (Index): 0
    Total Pages Processed (Other): 1539
    Total Pages Processed (Seg) : 0
    Total Pages Failing (Seg) : 0
    Total Pages Empty : 5588
    Total Pages Marked Corrupt : 0
    Total Pages Influx : 0
    Highest block SCN : 470536 (0.470536)
    You can use dbv utility for datafiles not for tempfiles, redolog file, controlfile etc.
    download-west.oracle.com/docs/cd/B10501_01/server.920/a96652/ch13.htm
    Regards
    Jafar

  • 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

  • RMAN problem with block corruption

    Hi
    I have problem with the block corruption in one of the database .
    here is the error message .
    ora-01578:oracle data block corrupted (file# 10,block # 55309) ora-01110: data file 10:
    '/db/gist1/data/gist1_gis_nologging_01.dbf' ora-26040: data block was loaded using the NOLOGGING option .
    gisq SQL> select * from v$database_block_corruption;
    FILE# BLOCK# BLOCKS CORRUPTION_CHANGE# CORRUPTIO
    10 11 126 3754364971 LOGICAL
    RMAN> blockrecover datafile 10 block 11;
    Starting blockrecover at 14/DEC/2012 16:25:48
    RMAN-00571: ===========================================================
    RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
    RMAN-00571: ===========================================================
    RMAN-03002: failure of blockrecover command at 12/14/2012 16:25:48
    RMAN-05009: Block Media Recovery requires Enterprise Edition
    Could some one help me in providing solution for this . we we have standard addition only .
    Thanks in advance ...

    It appears that there was a NOLOGGING operation on an object that resides in '/db/gist1/data/gist1_gis_nologging_01.dbf' .
    NOLOGGING operations, as the name suggests, do generate limited redo log, which makes the objects affected by them non-recoverable.
    RMAN Blockrecover, as far as I understand, uses full and archivelog backup to perform the block recovery. Since the archivelog backup does not store any changes related to the NOLOGGING operation, then Blockrecover would not be able to help you even if you were licensed.
    You can try to restore the object as of the most recent full backup…
    Iordan Iotzov
    http://iiotzov.wordpress.com/

Maybe you are looking for

  • Installing Windows 7 onto an external hard drive?

    So I got a 2TB external LaCie hard drive and my question is: can I install my copy of Windows 7 onto it using bootcamp?  I rarely use Windows7 so I just want to be able to plug in the external hard drive and boot from it whenever I need to use Window

  • T430 - HD 4000 - 3 Monitors - how to ?

    Hi Trying to get 3 monitors working with my current setup - i have 2 monitors working fine - i just want to add a third. I have a T430 with HD4000 - and the Minidock 90W - the 4337 model with VGA, DVI and Displayport. According to the spec for the mi

  • Can MS Virtual PC Access NI Hardware on the Host System?

    We use multiple versions of LabVIEW and NI-DAQ (legacy hardware) and I was considering using Microsoft's Virtual PC to create a Windows 2000 virtual PC on my Windows XP system to program the legacy code.  If I have a NI card (like a PCI-DIO-96) in my

  • TODATE function

    Hi, when i use todate function in the logical column TODATE(Core."Fact - HR - Payroll".PAY_ITEM_AMT, Core."Date"."Year") getting the following error. Query Status: Query Failed: [nQSError: 22046] To use TODATE function, the query level ('Year, Fiscal

  • Cover flow in Safari 4.0.3

    I'm running Safari 4.0.3 in Snow Leopard without too much trouble. I like cover flow (though I know it's mostly cosmetic) but many of my bookmarked sites won't show even after directly visiting them. Cover flow just displays a blank, though other sit