Standby DB recovery in case of block corruption

Hi all,
I have a question,can we recover the physical standby database if we take rman backup of rpimary db and restore it to the standby db.Please suggest me...

I have checked it through rman on the primary db and not found any block corruption....
  run {
       allocate channel d1 type disk;
       allocate channel d2 type disk;
       backup check logical validate database;
       release channel d1;
       release channel d2;
       }but i want ot forst test it on the test server but i don't know how to corrupt the block corruption i have opened the datafile and entered some character but i am getting other error not block corruption actually i want to test the sam scenario so that i will be confident while resotring the primary database to standby database.....
Edited by: user00726 on Feb 20, 2009 12:10 AM

Similar Messages

  • 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>

  • DB block corruption

    Hi All
    Is there any specific reason or what have possible to cause on the data block corruption in the oracle database.

    Block corruption is while the data is being written to the data blocks, if the write to the block fails abruptly, I mean that there is a partial write in the block, may be because of power disruption or I/O problem, leaving no time for header to be updated, or row data to be populated, oracle leaves the block corrupt.In case of block corruption you can normally use the database unless you try to read that particular block, against which it shoots up the block corruption error.Generally block corruption occurs if write fails on the block, when the transaction is being committed
    ORA-01578:
    ORACLE data block corrupted (file # string, block # string)
    Whenever we encounter above error message mean we have BLOCK CORRUPTION.
    We can find detail information about block corruption in alert.log file
    Two types of block corruption can happens
    - Physical corruption (media corrupt)
    - Logical corruption (soft corrupt)
    Physical corruption can be caused by defected memory boards, controllers or broken sectors on a hard disk;
    Logical corruption can among other reasons be caused by an attempt to recover through a NOLOGGING action.

  • Block corruption on Standby database

    Oracle 10g R2 64bit on Solaris 10 installed on two database server, Sun M5000 and Sun V890
    Primary and physical Standby database is configured with Max performance Async mode, log shipping is ok, archive logs are also applying..
    I opened the standby database on readonly mode, couple of SQLs are running successfully but few SQLS are throwing error meesaage, here is log message -
    SQL> select count(1) from inventory_stock;
    select count(1) from inventory_stock
    ERROR at line 1:
    ORA-01578: ORACLE data block corrupted (file # 12, block # 28109)
    ORA-01110: data file 12: '/backup1/np13/data/invindx01.dbf'
    ORA-26040: Data block was loaded using the NOLOGGING option
    However there is no error meesage recorded in Alert log files related to block corruption. Please suggest

    select file#,UNRECOVERABLE_CHANGE#,UNRECOVERABLE_TIME
    from V$DATAFILE
    where UNRECOVERABLE_TIME is not null
    FILE# UNRECOVERABLE_CHANGE# UNRECOVER
    4 9.7333E+12 12-SEP-10
    5 9.7333E+12 12-SEP-10
    6 9.7333E+12 12-SEP-10
    7 9.7333E+12 12-SEP-10
    9 9.7333E+12 12-SEP-10
    12 9.7333E+12 13-SEP-10
    13 9.7333E+12 13-SEP-10
    14 9.7327E+12 01-SEP-10
    15 9.7333E+12 13-SEP-10
    17 9.7333E+12 13-SEP-10
    22 9.7333E+12 13-SEP-10
    23 9.7333E+12 13-SEP-10
    24 9.7333E+12 13-SEP-10
    32 9.7333E+12 13-SEP-10
    33 9.7333E+12 13-SEP-10
    34 9.7333E+12 13-SEP-10
    35 9.7333E+12 13-SEP-10
    41 9.7324E+12 25-AUG-10
    42 9.7333E+12 13-SEP-10
    43 9.7333E+12 13-SEP-10
    44 9.7333E+12 13-SEP-10
    45 9.7333E+12 13-SEP-10
    57 9.7332E+12 11-SEP-10
    60 9.7333E+12 13-SEP-10
    62 9.7333E+12 12-SEP-10
    63 9.7333E+12 13-SEP-10
    65 9.7333E+12 13-SEP-10
    66 9.7333E+12 13-SEP-10
    68 9.7333E+12 13-SEP-10
    70 9.7333E+12 13-SEP-10
    71 9.7333E+12 12-SEP-10
    73 9.7333E+12 12-SEP-10
    74 9.7333E+12 13-SEP-10
    75 9.7333E+12 12-SEP-10
    77 9.7324E+12 25-AUG-10
    79 9.7333E+12 13-SEP-10
    83 9.7333E+12 13-SEP-10
    84 9.7333E+12 13-SEP-10
    86 9.7333E+12 13-SEP-10
    87 9.7333E+12 12-SEP-10
    89 9.7333E+12 12-SEP-10

  • Data block corrupted on standby database (logical corruption)

    Hi all,
    we are getting the below error on our DRSITE,it is MANUAL PHYSCIAL STANDBY DATABSE...
    The following error has occurred:
    ORA-01578: ORACLE data block corrupted (file # 3, block # 3236947)
    ORA-01110: data file 3: '/bkp/oradata/orcl_raw_cadata01'
    ORA-26040: Data block was loaded using the NOLOGGING option
    I have checked in the Primary database, that there are some object which are not being logged into the redo logfiles.....
    SQL> select table_name,INDEX_NAME,logging from dba_indexes where logging='NO'
    TABLE_NAME INDEX_NAME LOG
    MENU_MENUS NUX_MENU_MENUS_01 NO
    MENU_USER_MENUS MENU_USER_MENUS_X NO
    OM_CITY IDM_OM_CITY_CITY_NAME NO
    OM_EMPLOYER                    EMPLR_CODE_PK                  NO
    OM_EMPLOYER                    IDM_EMPLR_EMPLR_NAME           NOOM_STUDENT_HEAD OM_STUDENT_HEAD_HEAD_UK01 NO
    OT_DAK_ENTRY_DETL DED_SYS_ID_PK NO
    OT_DAK_ENTRY_HEAD DEH_SYS_ID_PK NO
    OT_DAK_ENTRY_HEAD IDM_DEH_DT_APPL_REGION NO
    OT_DAK_ENTRY_HEAD IDM_DEH_REGION_CODE NO
    OT_DAK_REFUNDS_DETL DRD_SYS_ID_PK NO
    TABLE_NAME INDEX_NAME LOG
    OT_MEM_FEE_COL_DETL IDM_MFCD_MFCH_SYS_ID NO
    OM_STUDENT_HEAD IDM_STUD_COURSE NO
    13 rows selected.
    so the main problem is in the OM_EMPOYER tables if i would delete the indexes from that table recreate it again with the logging clause,and then apply the archvied logs to the DRSITE.WILL THE problem will resolve.
    Pls suggest me...

    Hi..
    Firstly how did you confirm that it was that index only.Can you post the output of
    SELECT tablespace_name, segment_type, owner, segment_name
    FROM dba_extents WHERE file_id = 3 and 3236947 between block_id
    AND block_id + blocks - 1;
    This query can take time, if are sure that its the index don't fire this command .
    Secondly, when you will drop and recreate the index, it will be logged into the redo logfile.This information will be be logged in to an the archivelog file as its the replica of the redo logfile. Then when you apply this archive log maually, it will drop that index and then recreate it using the same sql.
    HTH
    Anand

  • Block corruption recovery!!

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

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

  • How to practice "Archived log sequences loss- Block corruptions recovery"

    Hello,
    Prepare and test a recovery scenarios
    - System Tablespace loss
    - Online Redolog loss
    - Controlfile loss
    - Data Tablespace loss
    - Single/multiple datafile loss
    - Archived log sequences loss- Block corruptions recovery
    - Total loss (database)
    - Total loss (server = database/software/parameter files)
    11g on windows
    I am practicing my rman recovery and found this list of recovery scenarios. I have completed all scenarios
    besides "Archived log sequences loss- Block corruptions recovery"
    How do I break the database for the snenario "Archived log sequences loss- Block corruptions recovery"?
    Do I delete the acr.001 files in directory I:\oracle\product\11.1.0\db_1\RDBMS? Then recovery as far forward as I can?
    thanks for your help.

    thanks for the tips
    11g on windows 2003
    I broke the database like this:
    rman backup
    shutdown immediate;
    deleted datafile 5
    delete most recent archivelogs seq 5 and 6;
    recovered like this:
    startup mount;
    restore datafile 5;
    recover datafile 5;
    alter database open;
    This does not seem correct? Did this also apply my archivelogs seq 5 and 6? Should I also do a point in time recovery?
    Should I also run this?
    run (set until sequence 6 thread 1; restore database; recover database;)
    thanks for any help

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

  • How to respond to physical block corruption??

    Hi, all.
    As far as I know, there are two types of block corruption.
    1. logical block corruption
    2. physical block corruption
    In case of logical block corruption, there are a few method of how to take care of it.
    such as BMR with rman, media recovery, and dbms package.
    In case of physical block corruption, how can I respond to this type of errors?
    Does physical block corruption of a disk mean disk failure??
    If so, I have to replace the disk? Or, is there any other way to solve
    this type of errors?
    In addition, how can I know that the block corruption is caused by logical problems
    or physical problems??
    Thanks and Regards.

    > In case of physical block corruption, how can I respond to this type of
    errors?
    Round around in circles, screaming at the top of your voice "we're all going to die!".
    Hey, why that funny looks? It works. And it scares the stuffings out of management and colleagues... ;-)
    > Does physical block corruption of a disk mean disk failure??
    If by physical corruption you mean that reading a data block results in I/O errors and a corrupt/incomplete read buffer, then yes. The "disk" is failing - or more correctly, the I/O h/w is failing. It may not be the disk itself. It could be a problem with the HBA, a controller card, etc.
    In exceptional cases it may not even be a h/w issue. It could be a s/w induced error. I once got physical I/O errors reported by Oracle. The problem was traced to an incompatibility between the ASMlib kernel module and EMC Powerpath. The SAN disks & h/w were fine.
    > If so, I have to replace the disk? Or, is there any other way to solve
    this type of errors?
    There should be some kind of diagnostics you can run on the disks to determine if they are failing. Simply replacing a disk because there seems to be a physical corruption problem may not solve the problem itself.
    You need to identify the actual problem. Which means looking at all Oracle traces/dumps in this regard, looking at the kernel logs, manually dumping blocks to see the results, using whatever I/O & disk diagnostic tools available, etc.
    > In addition, how can I know that the block corruption is caused by logical
    problems or physical problems??
    That depends on what you define as logical and physical corruption. The latter means to me that I cannot get the data off the disk without some kind of I/O error. Logical means that the data can be read just fine, but is garbage. Which could simply mean GIGO without implying any kind of underlaying h/w failure.

  • How to overcome from Data block corruption error

    Hi,
    I am using one table when i was deleting one row, i encountered "Data block corruption error".
    Kindly suggest solutions for the same.
    Regards,
    Abhishek

    If you have a recovery manager backup, then you can perform a block recovery operation, after the information shown on the error message where the file# and the block# are displayed you can perform the block recovery operation.
    Syntax for the block recovery operation can be found here : BLOCKRECOVER
    In case of an index block, it is enough to rebuild the index.
    In case you have a regular backup with archivelog enabled you can restore the damaged datafile and perform a simple file recovery operation.
    One more additional tip that can be used, you may be interested in using the DBMS_REPAIR package unit.
    Finally, I suggest you to check the complete datafile using dbv (Database Verifier) utility to find out if there are more corrupt blocks in your datafile, and proactively run this utility as a maintenance task.
    ~ Madrid

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

  • Data Block Corruption

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

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

  • Oracle V11.2.0.3 ORA-01578: ORACLE data block corrupted - OBJECT = IDL_UB1$

    Hi,
    I am running into a data corruption issue.
    My database is:
    SQL> select banner from v$version;
    BANNER
    Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - Production
    PL/SQL Release 11.2.0.3.0 - Production
    CORE 11.2.0.3.0 Production
    TNS for Linux: Version 11.2.0.3.0 - Production
    NLSRTL Version 11.2.0.3.0 - Production
    The following information is written to the alert.log File
    alert.log File
    Mon Nov 07 17:24:12 2011
    Starting ORACLE instance (normal)
    LICENSE_MAX_SESSION = 0
    LICENSE_SESSIONS_WARNING = 0
    Picked latch-free SCN scheme 2
    Using LOG_ARCHIVE_DEST_1 parameter default value as USE_DB_RECOVERY_FILE_DEST
    Autotune of undo retention is turned on.
    IMODE=BR
    ILAT =27
    LICENSE_MAX_USERS = 0
    SYS auditing is disabled
    Starting up:
    Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - Production.
    ORACLE_HOME = /home/oracle/dbhome
    System name: Linux
    Node name: dbl-ora
    Release: 2.6.18-274.3.1.el5 (This is rhel5.7 or CentOs5.7)
    Version: #1 SMP Tue Sep 6 20:14:03 EDT 2011
    Machine: i686 / vm
    Mon Nov 07 19:42:14 2011
    Corrupt Block Found
    TSN = 0, TSNAME = SYSTEM
    RFN = 1, BLK = 52346, RDBA = 4246650
    OBJN = 225, OBJD = 225, OBJECT = IDL_UB1$, SUBOBJECT =
    SEGMENT OWNER = SYS, SEGMENT TYPE = Table Segment
    Errors in file /home/oracle/diag/rdbms/ora11/K/trace/K_ora_5425.trc (incident=11053):
    ORA-01578: ORACLE data block corrupted (file # 1, block # 52346)
    ORA-01110: data file 1: '/home/oracle/oradata/ora11/system01.dbf'
    Incident details in: /home/oracle/diag/rdbms/ora11/K/incident/incdir_11053/K_ora_5425_i11053.trc
    I was even able to detect the row that is generating the issue.
    In my case the obj# 33573 until 33577 are causing the issue,
    though I have no idea what sort of objects are affected.
    SQL> select * from idl_ub1$ where obj#=33572;
    OBJ# PART VERSION PIECE# LENGTH P
    33572 1 0 0 9032 F
    SQL> select * from idl_ub1$ where obj#=33573;
    ERROR:
    ORA-01578: ORACLE data block corrupted (file # 1, block # 52346)
    ORA-01110: data file 1: '/home/oracle/oradata/ora11/system01.dbf'
    no rows selected
    SQL> select * from idl_ub1$ where obj#=33577;
    ERROR:
    ORA-01578: ORACLE data block corrupted (file # 1, block # 52358)
    ORA-01110: data file 1: '/home/oracle/oradata/ora11/system01.dbf'
    no rows selected
    SQL> select * from idl_ub1$ where obj#=33578;
    OBJ# PART VERSION PIECE# LENGTH P
    33578 1 0 0 9032 F
    Any idea, how to fix this problem without recreating the whole database?
    Thanks in advance.
    wmager
    Edited by: magerxr on Nov 7, 2011 8:27 AM

    magerxr wrote:
    Thanks again for your quick advise.
    Here comes the result of dbv against my system tablespace.
    [oracle@dbl-ora ~]$ dbv FILE=/home/oracle/oradata/ora11/system01.dbf
    DBVERIFY: Release 11.2.0.3.0 - Production on Mon Nov 7 22:39:11 2011
    Copyright (c) 1982, 2011, Oracle and/or its affiliates. All rights reserved.
    DBVERIFY - Verification starting : FILE = /home/oracle/oradata/ora11/system01.dbf
    Page 52346 is influx - most likely media corrupt
    Corrupt block relative dba: 0x0040cc7a (file 1, block 52346)
    Fractured block found during dbv:
    Data in bad block:
    type: 6 format: 2 rdba: 0x0040cc7a
    last change scn: 0x0000.0010acfa seq: 0x1 flg: 0x04
    spare1: 0x0 spare2: 0x0 spare3: 0x0
    consistency value in tail: 0x00000000
    check value in block header: 0x8fda
    computed block checksum: 0xaafbselect owner, segment_type, segment_name from dba_extents
    where file_id = 1 and 52346 between block_id and block_id+blocks-1;
    >
    Page 52347 is marked corrupt
    Corrupt block relative dba: 0x0040cc7b (file 1, block 52347)
    Bad header found during dbv:
    Data in bad block:
    type: 1 format: 6 rdba: 0x0000a206
    last change scn: 0xacfa.0040cc7b seq: 0x10 flg: 0x00
    spare1: 0xfa spare2: 0xac spare3: 0x401
    consistency value in tail: 0x00000000
    check value in block header: 0x0
    block checksum disabled
    select owner, segment_type, segment_name from dba_extents
    where file_id = 1 and 52347 between block_id and block_id+blocks-1;
    Page 52361 is marked corrupt
    Corrupt block relative dba: 0x0040cc89 (file 1, block 52361)
    Bad header found during dbv:
    Data in bad block:
    type: 1 format: 6 rdba: 0x0000a206
    last change scn: 0xacfb.0040cc89 seq: 0x10 flg: 0x00
    spare1: 0xfb spare2: 0xac spare3: 0x401
    consistency value in tail: 0x32298500
    check value in block header: 0x0
    block checksum disabled
    select owner, segment_type, segment_name from dba_extents
    where file_id = 1 and 52361 between block_id and block_id+blocks-1;
    >
    >
    DBVERIFY - Verification complete
    Total Pages Examined : 122880
    Total Pages Processed (Data) : 81298
    Total Pages Failing (Data) : 0
    Total Pages Processed (Index): 22307
    Total Pages Failing (Index): 0
    Total Pages Processed (Other): 3349
    Total Pages Processed (Seg) : 1
    Total Pages Failing (Seg) : 0
    Total Pages Empty : 15910
    Total Pages Marked Corrupt : 16
    Total Pages Influx : 1
    Total Pages Encrypted : 0
    Highest block SCN : 4064615 (0.4064615)post results from 3 SQL above

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

Maybe you are looking for

  • Replacement iMac A1058 17" Hard-Drive

    Hi guys. About 2 years ago my iMac began malfunctioning on start-up; A few clicking noises, and then to a folder with a flashing question mark. I was going away for uni at the time, so didn't do anything about it, leaving the problem until I got home

  • OIM 11g R1 - Restrict Role assignment

    Hello, is it possible, if a user have a special role, that no other roles can be assigned? For example: User1 have the role "Restricted" assigned. No other roles can be assigned to that users. Either SYS ADMIN cannot assign other roles. Only after th

  • Cannot change user name to access iCloud

    keep receiving the following message ....... That Apple ID is already in use.If this Apple ID was created by you, simply sign in with your Apple ID and password.If it does not belong to you, try again using a different name........ the apple id is mi

  • 4s plays constant loop of unknown tune when ringer is switched to "ON"

    it sounds like a kind of ringtone or alert, but it's nothing I can find anywhere on my phone, and nothing I have ever heard before. The tone is about 7-8 seconds long and it runs in a continuous loop for as long as I have the ringer switched to "on."

  • IPhoto Sharing with Videos?

    Is there any way to share videos stored in iPhoto 9 to another Mac using sharing within iPhoto? All I can see on the other Mac are the photos, the videos don't show up.