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

Similar Messages

  • 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

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

  • Datafile corrupted On standby database

    one of the datafile got corrupted in the standby database . when backing up with rman i got ora-15966 error .
    i found the corrupted datafile but i did not have any backups to recover .
    is there any way to recover the block corruption ?

    Hello,
    What's your Oracle version? OS? following link shows how to fix it , you can search oracle documentation according to your version.
    http://www.mpi-inf.mpg.de/departments/d5/teaching/ss05/is05/oracle/server.920/a96521/repair.htm#11355
    Regards

  • Creating standby database using data guard.

    Current Env:
    Oracle 11.2.0.1
    ASM
    Size 1.7T and growing.
    I'm rebuilding a standby database and need to use rman because of a few factors. In the past, I did a file copy create a standby control file config init.ora and it always worked.
    We have a database and had the stanby build; but someone issued a flashback and corrupted the standby database.
    Because of the size 1.7T and growing and we are now using ASM.
    My research is only showing building standby through rman using dupicate database command.
    I would like to copy the cold backup to a external drive and ship it to the standby site where I'll do the restore. This is because of time and bandwith required to rebuild the standby will interfere with operaitions for the period the files are being copied.
    So what would be the high level steps.
    1) get the cold backup
    2) create the standby control file
    3) ship the data via corrier
    4) restore the database
    5) and this is where i'm not sure. recover the standby control file - but during the restore of the database the "normal" control file will open and perhaps do a checkpoint. therefore the standby controlfile will be usless.
    6) recover the standby database.
    Has anyone accomplished this?
    As much specifics will be helpful. This system is operational and needs to be done right the first time.
    thanks,
    -Rob

    Thank you.
    1) I'm going to off load the cold backup to an external drive and have a courier take it to the DR site.
    Why, we are replicating the SAN over to the DR site. When SAN replication backs up Oracle becomes non-responsive. Therefore; sending the data over the pipe is not an option for the standby rebuild. Yea' that's the easy way to do it. But this system is operational and critical to operations; so we will not risk saturating the pipe for any period of time. The pipe got saturated one time and it was not pretty.
    2) I'm running the test in my lab to make sure I can create the standby database using the cold backup and rman.
    3) In the past it was easy; I got a cold backup of the data files using the same ksh scripts that have been working for 20 years. Copy the files over to the standby site, and put it into managed recovery. This technique has been working fine sense Oracle 8i days. ASM through a huge monkey wrench in the ksh script backup and now I'm forced to use rman. Hey, I'm told it's an okay product but when it comes to backups I never get fancy; that just makes things more complicated. Okay I wont complain about asm anymore, i guess there is an advantage in there somewhere.
    -Rob

  • Corrupt Block and Standby Database

    Guys,
    I created a standby database recently. I then discovered a corrupt block on my primary, I assume the corruption is also on the standby since the files were coppied. If I repair the corrupt block on the primary how do I move the correction to the standby, do I have to recreate it?
    DB version is 9iR2
    Delton

    Hi Delton,
    How do you plan to repair the corrupt block ?
    * Drop and re-create the object
    * Restore from backup
    In both cases, changes are replicated to the standby database, so nothing to worry about. As Sybrand has mentioned, make sure the changes are done with LOGGING option.
    Regards
    Asif Momen
    http://momendba.blogspot.com

  • DBV-0200,block already marked corrupted on physical standby database

    Dear all,
    we are facing the problem of *'DBV-200 that is block already marked corupted on standby database'* on all index datafile, we facing this error in oracle 10.2.0.3 version of database when we are running dbv utility.
    but this error can't found on our production database. It is only on standby database.
    We canot find the root cause of this error so any body tell me the cause and solution on this.
    Thanks
    Kiran Rane.

    Hi Ravi,
    i checked all indexes on our primary database some indexes is in logging mode and more than half indexes is in nologging mode but i have some doubt about index logging and nologging mode,
    when our primary database is running on 9.2.0.8 version of database this kind of error not observe but after upgrading to 10.2.0.3 version of database we are getting this kind of error so if this version having some bugs or for avoiding this error any patch is available. so tell me what is the exact reason behind this error.
    Thanks
    Kiran Rane.

  • 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

  • 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

  • StandBy Database goes Corrupt

    Hi,
    I'm new to Data Guard tech. I've installed Oracle 10g Data Guard on Solaris platform.
    However, while doing some operation i noticed that the control file of the StandBy db has been corrupted, soon after i took its backup (By Renaming it) and create new Control file from Primary DB and placed at same location with same name.
    As i restarted the Standby Db - it gave me an error of Datafile old and i got it as the SCN number has been changed with respect to new control file and Datafile.
    Currently, there is nothing in the DB's and both (Primary and Standby DB) are blank and will go in production after some days.
    Now, my Query is how to make them synchronize - how to make my StandBy Db in working condition???
    Note: >> If required, I can Shutdown Primary DB.
    >> Db is running in Archive Log mode but it got corrupted long back and i dont know the exact date of its corruption.
    While Surfing, i got at some site that:
    Create StandBy control file from Primary DB and place it at StandBy DB.
    Place all Datafiles and index and Redo log files form primary to StandBy DB And then try to start. Now please suggest - Will these steps make my StanDby Db working - Else Plz provide me the correct stpes ot make my StandBy Db working.
    PS: Both my DBs are empty currently.
    Thanks a lot for your help.

    mate I suggest that you do a number of different things.
    one is shut down the database and copy all the files to the standby database location,
    startup mount the production database and create the standby control file
    alter database create standby controlfile ' location /standby.ctl';then copy it to the location of the control files in your standby database. then delete all the control file there. and copy the standby in control01.ctl control02.ctl and control03.ctl
    the startup no mount your standby,
    alter database mount standby database; then get your connectivity to your production working by doing a conn to each database from the other one, ie. from the sql prompt on the production , connect to the standby,from the sql prompt on the standby connect to the production etc.
    if that is fine then on the production database at the prompt
    open it up
    alter database openon the standby database .
    alter database recover managed standby database disconnect from session;and it should go.

  • The password file is getting corrupted after rebooting the standby database

    Hi,
    The password file is getting corrupted after rebooting the standby database.
    Since the databases are not in sync, I had to copy the pwfile from primary to standby to make 'em sync.
    (BUT.... the pwfile is not getting corrupted every time I reboot the standby by)
    Could somebody please explain the reason for the pwfile on the standby database getting corrupted while rebooting ?
    Env: Oracle 11g on Windows 7
    Thanks in advance

    Moderator Action:
    This thread was originally posted to the Oracle/Sun Servers HARDWARE forum.
    This is definitely not an issue related to any hardware components.
    ... it's now moved to Database General Questions, hopefully for closer topic alignment.

  • 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

  • ORA-01578 about standby database in read only mode

    Hi,
    I have an ORA-05178 (data block corrupted) about a standby database which in read-only mode. About production database, there is no problem.
    After analyze, this is an index segment :
    SELECT segment_name , segment_type , owner , tablespace_name
    FROM sys.dba_extents
    WHERE file_id = 58
    AND 218173 BETWEEN block_id and block_id + blocks -1
    SEGMENT_NAME SEGMENT_TYPE OWNER TABLESPACE_NAME
    SICINHIS01 INDEX MOWIN IDX_DATA01
    There is no constraint.
    How can I repair this problem ?
    Nicolas

    Hi,
    I have an ORA-05178 (data block corrupted) about a standby database which in read-only mode. About production database, there is no problem.
    After analyze, this is an index segment :
    SELECT segment_name , segment_type , owner , tablespace_name
    FROM sys.dba_extents
    WHERE file_id = 58
    AND 218173 BETWEEN block_id and block_id + blocks -1
    SEGMENT_NAME SEGMENT_TYPE OWNER TABLESPACE_NAME
    SICINHIS01 INDEX MOWIN IDX_DATA01
    There is no constraint.
    How can I repair this problem ?
    Nicolas

  • Standby database recovery error

    Dear All,
    When Im trying to apply redologs for my standby database, the following error is coming up
    ORA-00279: change 276067636 generated at 08/22/2010 05:03:25 needed for thread 1
    ORA-00289: suggestion : /oracle/BWP/oraarch/BWParch1_30490_684267445.dbf
    ORA-00280: change 276067636 for thread 1 is in sequence #30490
    Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
    AUTO
    ORA-00283: recovery session canceled due to errors
    ORA-00368: checksum error in redo log block
    ORA-00353: log corruption near block 32769 change 276075175 time 08/22/2010 05:03:49
    ORA-00334: archived log: '/oracle/BWP/oraarch/BWParch1_30490_684267445.dbf'
    ORA-01112: media recovery not started
    Could you please help out.
    Thanks n Regards,
    KK

    Hi Stefan,
    Oracle data guard is implemented by one of the expert on the same.
    The following is result of the command you listed.
    NAME                                 TYPE        VALUE
    log_archive_dest                     string      /oracle/BWP/oraarch/BWParch
    log_archive_dest_1                   string
    log_archive_dest_10                  string
    log_archive_dest_2                   string
    log_archive_dest_3                   string
    log_archive_dest_4                   string
    log_archive_dest_5                   string
    log_archive_dest_6                   string
    log_archive_dest_7                   string
    log_archive_dest_8                   string
    log_archive_dest_9                   string
    NAME                                 TYPE        VALUE
    log_archive_dest_state_1             string      enable
    log_archive_dest_state_10            string      enable
    log_archive_dest_state_2             string      defer
    log_archive_dest_state_3             string      enable
    log_archive_dest_state_4             string      enable
    log_archive_dest_state_5             string      enable
    log_archive_dest_state_6             string      enable
    log_archive_dest_state_7             string      enable
    log_archive_dest_state_8             string      enable
    log_archive_dest_state_9             string      enable
    Thanks,
    Anees

  • Force logging at tablespace level for standby database

    Hi
    Can we create a standby database by enabling force logging at tablespace level instead of enabling it at database level.I want to out the tablespace containing indexes in nologging mode so that when I rebuild the indexes no logs will be generated.

    Technically, you can create a Standby without having set FORCELOGGING at the Primary database.
    You can also then selectively FORCELOGGING for all your important tablespaces (beginning with SYSTEM, SYSAUX, UNDO ....)
    However, for a Physical Standby Redo Apply will mark the blocks (e.g. those populated by the CREATE INDEX .. NOLOGGING) as "corrupt". You will get Read Errors (ORA-1578 and ORA-26040) when you attempt to read the index (e.g. for a Table query).
    So you have to monitor your NOLOGGING operations and the datafiles where NOLOGGING is applied. You can take Incremental RMAN Backups of such datafiles and restore them to the Standby immediately after the NOLOGGING operations.
    Hemant K Chitale

Maybe you are looking for

  • SSO to Documentum eRoom

    Hi, is there a way to implement eRoom using Single Sign On to our EP6 SP2 Portal? I know there were iViews for EP5 available, but what about EP6 SP2? We would like to use SAP logonticket and not usermapping. Thanks for any help, Holger.

  • Importing VHS tapes w/ADVC-300 help

    Please help, I'm converting a large number of VHS tapes to DVD using a ADVC-300 Analog to Digital Converter and a Sony VCR. Everything imports fine but everytime the signal hits a break in the tape (the old VHS snowstorm) iMovie stops importing. Sinc

  • How do I put a shot cut to my desktop from amazon website?

    I want a link of Amazon homepage on my desktop and can't figure out how to do it.

  • Migration problem with new macboo

    Hi all, I have, what I hope is, a newbie question. I used migration assistant to transfer data from my imac 20 to the new macbook. The goal was to transfer itunes, docs, etc. What I seem to have gotten is virtually everything including duplicate prog

  • Aftermarket mouse and keyboard

    I'm looking to see if there's any good aftermarket wireless keyboards and mice that are Mac specific? I'd prefer black as well since I have a black MacBook. I've looked around and most of the wireless keyboards and mice that are PC and Mac compatible