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,
-RobThank 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
DeltonHi 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
StefanThanks 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 -
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 advanceModerator 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. -
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
SureshHi 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 ?
NicolasHi,
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,
KKHi 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
-
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