Corrupted datafiles in standby

Hello
I used to have three indexes in nologging mode in primary database.
When I scan the datafiles of these indexes in standby database, I notice that datafiles are logically corrupted.
Today, I dropped these indexes in primary database and recreated them with logging. Archivelogs of these steps were also applied to standby.
Even there is no obect in nologging mode, When I scan the datafiles in standby, somehow they are still logically corrupted !!!!!!!!!!
What is the reason for that?
Cheers

Mr Sb;
They are created as logging.
It is really difficult to grasp this.
Here is the output of one of the corrupted datafile with dbv
DBV-00200: Block, dba -2126348425, already marked corrupted
DBV-00200: Block, dba -2126348424, already marked corrupted
DBV-00200: Block, dba -2126348423, already marked corrupted
DBV-00200: Block, dba -2126348422, already marked corrupted
DBV-00200: Block, dba -2126348421, already marked corrupted
DBV-00200: Block, dba -2126348420, already marked corrupted
DBV-00200: Block, dba -2126348419, already marked corrupted
DBV-00200: Block, dba -2126348418, already marked corrupted
DBV-00200: Block, dba -2126348417, already marked corrupted
DBV-00200: Block, dba -2126348416, already marked corrupted
DBV-00200: Block, dba -2126348415, already marked corrupted
DBV-00200: Block, dba -2126348414, already marked corrupted
DBV-00200: Block, dba -2126348413, already marked corrupted
DBV-00200: Block, dba -2126348412, already marked corrupted
DBV-00200: Block, dba -2126348411, already marked corrupted
DBV-00200: Block, dba -2126348410, already marked corrupted
DBV-00200: Block, dba -2126348409, already marked corrupted
DBV-00200: Block, dba -2126348408, already marked corrupted
DBV-00200: Block, dba -2126348407, already marked corrupted

Similar Messages

Logically corrupted blocks in standby

Hi
Assume I have a primary database and standby database.
Accidentally, Some of the objects (indexes and tables) are in nologging mode in primary database.
Force logging is not set.
When I scan the datafiles in standby I realize that some datafiles are logically corrupted because of this issue.
How can I get rid of these corrupted blocks?
If I rebuild indexes with logging option, and recreate table as logging,
Will it solve the problem? or any other suggestion
Many thanks

Sivok wrote:
Hi
Assume I have a primary database and standby database.
Accidentally, Some of the objects (indexes and tables) are in nologging mode in primary database.
Force logging is not set.
When I scan the datafiles in standby I realize that some datafiles are logically corrupted because of this issue.
How can I get rid of these corrupted blocks?
If I rebuild indexes with logging option, and recreate table as logging,
Will it solve the problem? or any other suggestion
Many thanksyour primary should run in force logging mode (ALTER DATABASE FORCE LOGGING) then the object level setting is ignored for direct path operations. You can apply an incremental backup to the standby to catchup (or just recreate the standby which might be as quick depending on volumes).
Niall Litchfield
http://www.orawin.info/

Relocating datafiles on standby database after mount point on stanby is ful

Hi,
We have a physical standby database.
The location of datafiles on primary database are at /oracle/oradata/ and the location of datafiles on standby database are at /oracle/oradata/
Now we are facing a situation of mount mount getting full on standby database so we need to move some tablespaces to another location on standby.
Say old location is /oracle/oradata/ and new location is /oradata_new/ and the tablespaces to be relocated are say tab1 and tab2.
Can anybody tell me whether following steps are correct.
1. Stop managed recovery on standby database
alter database recover managed standby database cancel;
2. Shutdown standby database
shutdown immediate;
3. Open standby database in mount stage
startup mount;
4. Copy the datafiles to new location say /oradata_new/ using os level command
4. Rename the datafile
alter database rename file
'/oracle/oradata/tab1.123451.dbf', '/oracle/oradata/tab1.123452.dbf','/oracle/oradata/tab2.123451.dbf',''/oracle/oradata/tab2.123452.dbf'
to '/oradata_new/tab1.123451.dbf', '/oradata_new/tab1.123452.dbf','/oradata_new/tab2.123451.dbf',''/oradata_new/tab2.123452.dbf';
5. Edit the parameter db_file_name_convert
alter system set db_file_name_convert='/oracle/oradata/tab1','/oradata_new/tab1','/oracle/oradata/tab2','/oradata_new/tab2'
6. Start a managed recovery on standby database
alter database recover managed standby database disconnect from session;
I am littelbit confused in step 5 as we want to relocate only two tablespaces and not all tablespaces so we have used.
Can we use db_file_name_convert like this i.e. does this work for only two tablespaces tab1 and tab2.
Thanks & Regards
GirishA

http://download.oracle.com/docs/cd/B19306_01/server.102/b14239/manage_ps.htm#i1010428
8.3.4 Renaming a Datafile in the Primary Database
When you rename one or more datafiles in the primary database, the change is not propagated to the standby database. Therefore, if you want to rename the same datafiles on the standby database, you must manually make the equivalent modifications on the standby database because the modifications are not performed automatically, even if the STANDBY_FILE_MANAGEMENT initialization parameter is set to AUTO.
The following steps describe how to rename a datafile in the primary database and manually propagate the changes to the standby database.
To rename the datafile in the primary database, take the tablespace offline:
SQL> ALTER TABLESPACE tbs_4 OFFLINE;
Exit from the SQL prompt and issue an operating system command, such as the following UNIX mv command, to rename the datafile on the primary system:
% mv /disk1/oracle/oradata/payroll/tbs_4.dbf
/disk1/oracle/oradata/payroll/tbs_x.dbf
Rename the datafile in the primary database and bring the tablespace back online:
SQL> ALTER TABLESPACE tbs_4 RENAME DATAFILE 2> '/disk1/oracle/oradata/payroll/tbs_4.dbf'
3> TO '/disk1/oracle/oradata/payroll/tbs_x.dbf';
SQL> ALTER TABLESPACE tbs_4 ONLINE;
Connect to the standby database, query the V$ARCHIVED_LOG view to verify all of the archived redo log files are applied, and then stop Redo Apply:
SQL> SELECT SEQUENCE#,APPLIED FROM V$ARCHIVED_LOG ORDER BY SEQUENCE#;
SEQUENCE# APP
8 YES
9 YES
10 YES
11 YES
4 rows selected.
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
Shut down the standby database:
SQL> SHUTDOWN;
Rename the datafile at the standby site using an operating system command, such as the UNIX mv command:
% mv /disk1/oracle/oradata/payroll/tbs_4.dbf /disk1/oracle/oradata/payroll/tbs_x.dbf
Start and mount the standby database:
SQL> STARTUP MOUNT;
Rename the datafile in the standby control file. Note that the STANDBY_FILE_MANAGEMENT initialization parameter must be set to MANUAL.
SQL> ALTER DATABASE RENAME FILE '/disk1/oracle/oradata/payroll/tbs_4.dbf'
2> TO '/disk1/oracle/oradata/payroll/tbs_x.dbf';
On the standby database, restart Redo Apply:
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE
2> DISCONNECT FROM SESSION;
If you do not rename the corresponding datafile at the standby system, and then try to refresh the standby database control file, the standby database will attempt to use the renamed datafile, but it will not find it. Consequently, you will see error messages similar to the following in the alert log:
ORA-00283: recovery session canceled due to errors
ORA-01157: cannot identify/lock datafile 4 - see DBWR trace file
ORA-01110: datafile 4: '/Disk1/oracle/oradata/payroll/tbs_x.dbf'

How to diagnose and recover corrupted datafile?

DBMS: Oracle v.9.2.0.1.0
OS: MS Server 2003 R2 SP2 x86
Problem: Database begin to stop every few minutes. I start to check and found that one and the largest of two datafiles is probably corrupted. Now I have no idea how to repair that datafile.
Firstly, I look into the alert.log and see that^
Mon Jul 29 11:02:03 2013
SMON: enabling tx recovery
Mon Jul 29 11:02:03 2013
Database Characterset is CL8MSWIN1251
replication_dependency_tracking turned off (no async multimaster replication found)
Completed: alter database open
Mon Jul 29 11:02:42 2013
KCF: write/open error block=0x3c009f online=1
     file=4 F:\ORACLE\ORADATA\ORCL\USERS_1.ORA
     error=27069 txt: 'OSD-04026: Invalid parameter passed. (OS 3932319)'
Mon Jul 29 11:02:42 2013
Errors in file c:\oracle\admin\orcl\bdump\orcl_dbw0_3604.trc:
ORA-01242: data file suffered media failure: database in NOARCHIVELOG mode
ORA-01114: IO error writing block to file 4 (block # 3932319)
ORA-01110: data file 4: 'F:\ORACLE\ORADATA\ORCL\USERS_1.ORA'
ORA-27069: skgfdisp: attempt to do I/O beyond the range of the file
OSD-04026: Invalid parameter passed. (OS 3932319)
DBW0: terminating instance due to error 1242
Instance terminated by DBW0, pid = 3604
Dump file c:\oracle\admin\orcl\bdump\alert_orcl.log
So, I turned archivelog on and open database but it continue to stop when somebody calls to some DB objects.
Then, I check v$headers:
SQL> select file#, status, recover, fuzzy, tablespace_name, to_char(CHECKPOINT_CHANGE#), name from v$datafile_header;
FILE# STATUS REC FUZ TABLESPACE_NAME      TO_CHAR(CHECKPOINT_CHANGE#)              NAME
         1 ONLINE NO YES SYSTEM               9679059694215                            F:\ORACLE\ORADATA\ORCL\SYSTEM.ORA
         2 ONLINE NO YES UNDO                 9679059694215                            F:\ORACLE\ORADATA\ORCL\UNDO.ORA
         3 ONLINE NO YES USERS                9679059694215                            F:\ORACLE\ORADATA\ORCL\USERS.ORA
         4 OFFLINE YES YES USERS                9679059697551                            F:\ORACLE\ORADATA\ORCL\USERS_1.ORA
For some reason, USERS in USERS_1.ORA is offline and marked as requiring recovery.
I tried to recover datafile, but get some errors:
SQL> recover datafile 'F:\ORACLE\ORADATA\ORCL\USERS_1.ORA';
ORA-00283: recovery session canceled due to errors
ORA-01115: IO error reading block from file 4 (block # 3932319)
ORA-01110: data file 4: 'F:\ORACLE\ORADATA\ORCL\USERS_1.ORA'
ORA-27069: skgfdisp: attempt to do I/O beyond the range of the file
OSD-04026: Invalid parameter passed. (OS 3932319)
That have looking creepy for me.
I tries to verify datafile:
dbv file=F:\oracle\oradata\orcl\users_1.ora blocksize=16384 logfile=F:\oracle\oradata\orcl\dbvlog.txt
The result of verification was unexpectedly clean:
DBVERIFY: Release 9.2.0.1.0 - Production on Tue Jul 30 05:03:26 2013
Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.
DBVERIFY - Verification starting : FILE = F:\oracle\oradata\orcl\users_1.ora
DBVERIFY - Verification complete
Total Pages Examined         : 3932320
Total Pages Processed (Data) : 94051
Total Pages Failing   (Data) : 0
Total Pages Processed (Index): 19378
Total Pages Failing   (Index): 0
Total Pages Processed (Other): 3753059
Total Pages Processed (Seg) : 0
Total Pages Failing   (Seg) : 0
Total Pages Empty            : 65832
Total Pages Marked Corrupt   : 0
Total Pages Influx           : 0
Now I have that offlined tablespace in the probably not corrupted datafile and no idea how to get DB into the normal state.
Upd: I did database validation by RMAN:
RMAN> BACKUP VALIDATE DATABASE;
Starting backup at 30-JUL-13
using target database controlfile instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=11 devtype=DISK
channel ORA_DISK_1: starting full datafile backupset
channel ORA_DISK_1: specifying datafile(s) in backupset
including current controlfile in backupset
input datafile fno=00004 name=F:\ORACLE\ORADATA\ORCL\USERS_1.ORA
input datafile fno=00002 name=F:\ORACLE\ORADATA\ORCL\UNDO.ORA
input datafile fno=00003 name=F:\ORACLE\ORADATA\ORCL\USERS.ORA
input datafile fno=00001 name=F:\ORACLE\ORADATA\ORCL\SYSTEM.ORA
channel ORA_DISK_1: backup set complete, elapsed time: 00:33:06
Finished backup at 30-JUL-13
That would been check my DB and put information of corrupted blocks to a V$DATABASE_BLOCK_CORRUPTION, but no! There's nothing:
SQL> select * from V$DATABASE_BLOCK_CORRUPTION;
no rows selected
Nevertheless, database doesn't open, until I switch bad datafile to offline^
SQL> alter database datafile 'F:\ORACLE\ORADATA\ORCL\USERS_1.ORA' online;
Database altered.
SQL> alter database open;
alter database open
ERROR at line 1:
ORA-01113: file 4 needs media recovery
ORA-01110: data file 4: 'F:\ORACLE\ORADATA\ORCL\USERS_1.ORA'
Message was edited by: Llywelyn.yv

Does it diferents from below?
RMAN> BACKUP VALIDATE DATABASE;
Starting backup at 30-JUL-13
using target database controlfile instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=11 devtype=DISK
channel ORA_DISK_1: starting full datafile backupset
channel ORA_DISK_1: specifying datafile(s) in backupset
including current controlfile in backupset
input datafile fno=00004 name=F:\ORACLE\ORADATA\ORCL\USERS_1.ORA
input datafile fno=00002 name=F:\ORACLE\ORADATA\ORCL\UNDO.ORA
input datafile fno=00003 name=F:\ORACLE\ORADATA\ORCL\USERS.ORA
input datafile fno=00001 name=F:\ORACLE\ORADATA\ORCL\SYSTEM.ORA
channel ORA_DISK_1: backup set complete, elapsed time: 00:33:06
Finished backup at 30-JUL-13

Corrupt Datafiles following "Successful" Clone Process

Looking for help with the following problem/issue:
We attempted to clone our production database to our development environment using RMAN, following a process successfully used on multiple occasions in the past.
Both databases are running on UNIX and are versoin 11.2.0.2.7 (with JUL2012 PSU applied).
The RMAN cloning operation completed WITHOUT errors AND, the new database can be shutdown, started, and accessed via SYS logoin, but all attempts by users to access the databsae returns "corrupt datafile" message on most datafiles.
Below is what we are seeing in the alert log:
Tue Nov 06 19:52:39 2012
Hex dump of (file 230, block 26214385) in trace file /oracle/app/oracle/diag/rdbms/IDB/trace/IDB_j000_16046.trc
Corrupt block relative dba: 0x018ffff1 (file 230, block 26214385)
Completely zero block found during buffer read
Reading datafile '/oradata/IDB/undotbs_02.dbf' for corruption at rdba:
0x018ffff1 (file 230, bock 26214385)
Reread (file 230, block 26214385) found same corrupt data (no logical check)
Tue Nov 06 19:52:39 2012
Corrupt Block Found
TSN = 31, TSNAME = UNDOTBS_02
RFN = 1024, BLK = 26214385, RDBA = 26214385
OBJN = .1, OBJD = -1, OBJECT = , SUBONJECT =
SEGMENT_OWNER = , SEGMENT_TYPE =
Errors in file /oracle/app/oracle/diag/rdbms/IDB/trace/IDB_j000_16046.trc (incident 36257):
ORA-01578: ORACLE data block corrupted (file # 230, block # 26214385)
ORA-01110: data file 230: '/oradata/IDB/undotbs_02.dbf'
Incident details in /oracle/app/oracle/dia/rdbms/IDB/incident/incdir_36257/IDB_j000_16046_i36257.trc
Trace File Content:
Hex dump of (file 230, block 26214385)
Dump of memory from 0x00000004877BE000 to 0x00000004877C0000
4877BE000 00A20000 018FFFF1 00000000 00000101 [................]
4877BE010 00000000 00000000 00000000 00000000 [................]
Repeat 509 times
4877BFFF0 00000000 00000000 00000000 00000001 [................]
Corrupt block relative dba: 0x018ffff1 (file 230, block 26214385)
Completely zero block found during buffer read
Reading datafile /oradata/IDB/undotbs_02.dbf' for corruptoin at rdba:
0x018ffff1 (file 230, block 26214385)
Reread (file 230, block 26214385) found same corrupt data (no logical check)
DDE: Problem Key 'ORA 1110' was flood controlled (0x5) (no incdent)
ORA-01110: data file 230: '/oradata/IDB/undotbs_02.dbf'
Byte offset to file# 230 block 26214385 is 4294844416
This is the FIRST attempt to clone the production database since the installation of the JUL2012 patch -- and this is the ONLY change to all servers since the last successful cloning.
We have since attempted cloning between different environments (to rule out server specific issue) and cloning to new mount points (to rule out h/w issue), but eah attempt results in the same errors.
If anyone has experienced this same issue/problem, any insight is welcome. Anyone with viable options, ideas also welcome.
Our next approach will be to uninstall patches since our last "good" cloning and attempt again.
Thanks!

Yes, but the UNDO tablespace is just one of many --- in fact, most tablespaces are affected, including the SYSTEM tablespace.
Following one clone attempt, we were able to manually correct a large portion of the corruption errors and make the instance accessible, but any attempt to access indexes and/or modify data, resulted in corruption messages.

Restoring and recovering datafiles in standby database

Hi,
oracle version : 8i(8.1.7.0.0)
os : sun solaris
I have scenerio where i lost some of the datafiles in standby database(physical standby) and i do have standby cold backup 3 months older since database size is 1TB is can i restore the the only lost files from cold backup and recover using archivelog files. since i only lost 4 data files of size 4gb each it will be faster compare to restoring the whole TB size database.
appreciated for valuable inputs.
Thanks
Prakash GR

Normal copy command can do your work:
sys@SANTU> startup
ORACLE instance started.
Total System Global Area 535662592 bytes
Fixed Size                  1334380 bytes
Variable Size             180355988 bytes
Database Buffers          348127232 bytes
Redo Buffers                5844992 bytes
Database mounted.
Database opened.
sys@SANTU> archive log list
Database log mode              Archive Mode
Automatic archival             Enabled
Archive destination            USE_DB_RECOVERY_FILE_DEST
Oldest online log sequence     4
Next log sequence to archive   6
Current log sequence           6
sys@SANTU> host copy D:\APP\SANTOSKU\ORADATA\SANTU\USERS01.DBF d:\
        1 file(s) copied.
sys@SANTU> shu immediate
Database closed.
Database dismounted.
ORACLE instance shut down.
*Renamed the datafile 'D:\APP\SANTOSKU\ORADATA\SANTU\USERS01.DBF' to 'D:\APP\SANTOSKU\ORADATA\SANTU\USERS011.DBF'*
sys@SANTU> startup
ORACLE instance started.
Total System Global Area 535662592 bytes
Fixed Size                  1334380 bytes
Variable Size             180355988 bytes
Database Buffers          348127232 bytes
Redo Buffers                5844992 bytes
Database mounted.
ORA-01157: cannot identify/lock data file 4 - see DBWR trace file
ORA-01110: data file 4: 'D:\APP\SANTOSKU\ORADATA\SANTU\USERS01.DBF'
sys@SANTU> host move d:\USERS01.DBF D:\APP\SANTOSKU\ORADATA\SANTU\
sys@SANTU> shu immediate
ORA-01109: database not open
Database dismounted.
ORACLE instance shut down.
sys@SANTU> startup
ORACLE instance started.
Total System Global Area 535662592 bytes
Fixed Size                  1334380 bytes
Variable Size             180355988 bytes
Database Buffers          348127232 bytes
Redo Buffers                5844992 bytes
Database mounted.
ORA-01113: file 4 needs media recovery
ORA-01110: data file 4: 'D:\APP\SANTOSKU\ORADATA\SANTU\USERS01.DBF'
sys@SANTU> recover datafile 'D:\APP\SANTOSKU\ORADATA\SANTU\USERS01.DBF';
Media recovery complete.
sys@SANTU> alter database open;
Database altered.
sys@SANTU>N.B. I have not done the demo on standby database.
but just i want to know is this procedure is valid that is instead of taking the lost datafiles from production can i use lost datafiles from standby database to recover other standby database.That would be fine.
Regards,
S.K.
Edited by: Santosh Kumar on Oct 8, 2009 11:09 AM

How to add datafile to standby database

Hi,
We have standby database on another site and we are using manual recovery. How to add datafile to standby database after datafile is added to primary database.
We are on Oracle 9i R2.
Please help.
Thanks in advance

Hi,
When you recover the standby database after you added a datafile to the production, you will get an error that the file that needs recovery does not exist.
At this point you can connect to the standby and issue:
alter database create datafile '<original_name>' as '<new_name>';the new name is optional if the location of the files are the same.
After that, you can continue recovering the standby database.
Liron Amitzi
Senior DBA consultant
[www.dbsnaps.com]
[www.orbiumsoftware.com]

Maxdb has corrupt datafile

Hi Everyone,
I have my content server running Maxdb 7.3 and it ran out of space when the autoextend was tring to add a datafile. The database is not able to start now due to the corrupt datafile. Can you offer any assistance?
Is it possible to upgrade to a later version of MaxDb with the database in its current state? I see the later versions have recovery commands but they do not work in this version of the DB.
Edited by: NIS Basis Support on May 10, 2010 11:48 PM

HI there,
if you're a SAP customer, please do open a support message for this.
Anyhow, just a few comments:
1) in 7.3 there is no such thing as autoextend. Additional Devspaces must be added manually.
2) Of course SAP DB 7.3 offers recovery commands and if fact most recovery options you find in 7.6 were already present in 7.3
3) Even if you've got a totally messed up database now, it should be possible to take a log backup now (to save all yet unsaved log entries) and to perform a complete restore/recovery of the database to a new instance.
If your backup setup is OK you should be able to have your database up and running again that way.
regards,
Lars

Open database with corrupt datafile

hi.. all
i'm use oracle10g R2 on RHEL 3 ,because power outage my datafile INDEXES.dbf was corrupted and i can't open my database with this corrupted datafile , i'm try to recover the corrupted block with blockrecover command using RMAN and block recover finished and i'm still cann't open my database .
SQL> alter database open ;
alter database open
ERROR at line 1:
ORA-01115: IO error reading block from file 6 (block # 98473)
ORA-01110: data file 6: '/home/oracle/oradata/branch16/INDEXES.dbf'
ORA-27072: File I/O error
Linux Error: 5: Input/output error
Additional information: 4
Additional information: 98473
Additional information: -1
i'm run my db in noarchivelog mode.
i need to open my database ( i have a dump file for my schema from yesterday)
please help me

Hi
If block level recovery is fin thru RMAN then open the database in mount state then do recover database and then open the database.
The above procedure is not work then you need to recreate the controlfile with existing datafile except that corrupt file. After recreating do full imp. It will solve the issue.
Regards
N.Sirajudeen

Recover corrupted datafile

I created database from cold backup and db is up and running. After recovery identified some datafiles has corruption with dbfsize.
Could anybody please help me how to recover corrupted datafile from cold backup?

sorry in my first message I mentioned I verified with dbfsize. It is not dbfsize it is dbv than I found some files has corruption. I db verified original backup datafiles those file are fine no corruption. The problem is while copying the files to the new location some corruption happened. Now I will try to copy original file and dbv first. Now I to recover bad datafiles? I need some steps. Thanks in advance.
Please provide your Oracle version, OS , the actual ORA- errorsOracle version is 9.2.0.7.0
OS SunOS 9
when I run dbv I got big list of errors copied portion of it....
$cat DEEFF.log |more
DBVERIFY: Release 9.2.0.7.0 - Production on Fri Feb 27 00:20:14 2008
Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.
DBVERIFY - Verification starting : FILE = /u01/oracle/DEEFF.dbf
Page 1024 is marked corrupt
Corrupt block relative dba: 0x1f400400 (file 125, block 1024)
Bad header found during dbv:
Data in bad block -
type: 6 format: 2 rdba: 0x1ac580dd
last change scn: 0x0004.f72fdb41 seq: 0x1 flg: 0x04
consistency value in tail: 0xdb410601
check value in block header: 0xb656, computed block checksum: 0x0
spare1: 0x0, spare2: 0x0, spare3: 0x0
Page 1025 is marked corrupt
Corrupt block relative dba: 0x1f400401 (file 125, block 1025)
Bad header found during dbv:
Data in bad block -
type: 6 format: 2 rdba: 0x1dc6d021
last change scn: 0x0002.f8bcf84b seq: 0x1 flg: 0x06
consistency value in tail: 0xf84b0601
check value in block header: 0x5983, computed block checksum: 0x0
spare1: 0x0, spare2: 0x0, spare3: 0x0
Page 1026 is marked corrupt
Corrupt block relative dba: 0x1f400402 (file 125, block 1026)
Bad header found during dbv:
Data in bad block -
type: 6 format: 2 rdba: 0x1e415f13
last change scn: 0x0004.3e23e1dd seq: 0x1 flg: 0x04
consistency value in tail: 0xe1dd0601
check value in block header: 0x502f, computed block checksum: 0x0
spare1: 0x0, spare2: 0x0, spare3: 0x0
Message was edited by:
Gud

Drop a partition with a corrupt datafile in the associated tablespace

Hello,
I desperately need to drop a partition. However, I am unable to do so as the datafile in the associated tablespace for the partition is corrupt. When I attempt to drop the partition, I receive the following error:
ORA-00376: file 16 cannot be read at this time.
ORA-01110: data file 16: '/data3/oradata/cdn/data/tran_part_20051115.dbf'
Is there any way to get rid of the corrupted datafile so that I can successfully drop the partition? Maintaining the data is not a concern at this point. The priority is to solve this issue, so data loss is not a concern for me.
Any assistance would be greatly appreciated!
Thanks,
Scott

Does the file '/data3/oradata/cdn/data/tran_part_20051115.dbf' exist on the disk?
What does; select distinct status from V$recover_file indicate?
Thanks
Chandra Pabba

Instance does not open, because of corrupted datafile

Hi
I am running 10gR2.
For a test I have corrupted the header of an test datafile of a non system tablespace when instance was closed.
Now when I started the instance it does not open with an alert entry
Errors in file c:\oracle\oracle\product\10.2.0\db_1\admin\orcl\bdump\orcl_dbw0_512.trc:
ORA-01157: cannot identify/lock data file 11 - see DBWR trace file
ORA-01110: data file 11: 'C:\ORACLE\ORADATA\ORCL\DAMAGE_DATA.DBF'
ORA-27046: file size is not a multiple of logical block size
Now how to proceed?
When I tried to set the tablespace offline I got:
SQL> alter tablespace damage_data_ts offline;
alter tablespace damage_data_ts offline
ERROR at line 1:
ORA-01109: database not open
Can I just drop the datafile ?
I forgot to include, that the datafile is the only file the tablespace got.
But even the dropping the tablespace giving error, saying the database is not open
SQL> DROP TABLESPACE damage_data_ts INCLUDING CONTENTS AND DATAFILES;
DROP TABLESPACE damage_data_ts INCLUDING CONTENTS AND DATAFILES
ERROR at line 1:
ORA-01109: database not open
Thanks

Now I was able to drop the datafile with:
SQL> shutdown immediate;
ORA-01109: database not open
Database dismounted.
ORACLE instance shut down.
SQL> startup mount;
ORACLE instance started.
Total System Global Area 612368384 bytes
Fixed Size 1250452 bytes
Variable Size 247466860 bytes
Database Buffers 360710144 bytes
Redo Buffers 2940928 bytes
Database mounted.
SQL> alter database datafile 'C:\oracle\oradata\orcl\DAMAGE_DATA.DBF' offline drop;
Database altered.

Error in adding datafile in standby databse.

Hi all.
My Environment is as below:
Oracle-8.1.7.4.0
OS-HP Unix-11
Primary database (only 1): Production
Standby database: Different Machine but same location (HP box)
Yesterday I have added 2 datafiles to the two different tablespace. I have checked file is available at Production box and one of the file also avilable at standby databse.
When I am following steps for applying redo log to the standby manually.
I got error.
SVRMGRL>connect internal
SVRMGRL>show parameter db_name
SVRMGRL>recover standby databse
After above step I got the Error:
ORA-00283 recovery session canceled due to error
ORA-01157 can not identify/lock datafile 24 -see DBWR trace file
ORA-01110 data file 24: '/location of .dbf file on standby databse disk'
Please let me know in detail because I am new in this field.
Thanks in advance

You will have the datafile information on the standby alert log.
Something like '/u01/app/oracle/product/8174/db/<filename>.dbf'.
1. connect as sysdba on standby database.
2. alter database create datafile 'Production datafile name' as 'alert log filename';
Example :
alter database create datafile '/u01/data/user1.dbf'
as '/u01/app/oracle/product/8174/db/<filename>.dbf';
3. Recovery managed standby database;
HTH.
Regards,
Arun

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.

Lost datafile on Standby Oracle 10g

Hi all.
i have lost one datafile on my standby ,how to recover it ,this file is created when primary database is in noarchive mode (before i set up the data guard) ,so i can't use alter database create datafile statement bocz i dont have all the archive log to recover it ,
plz help me out to solve this ..

969752 wrote:
Hi all.
i have lost one datafile on my standby ,how to recover it ,this file is created when primary database is in noarchive mode (before i set up the data guard) ,so i can't use alter database create datafile statement bocz i dont have all the archive log to recover it ,
plz help me out to solve this ..What is the version you are using?
Even though your primary database is in noarchive log mode before configuring data guard, still its not a problem. Follow high level steps as below
1) Take missing datafile on primary using RMAN (or) you can use tablespace backup with traditional method
2) copy that datafile from primary to standby system
3) Ensure you have properly set for DB_FILE_NAME_CONVERT(bounce required), and set standby_file_management to manual
4) take the dummy file and rename with the new file(step 2) by using alter database create command
5) later change standby_file_managment to auto & start MRP

Corrupted datafiles in standby

Similar Messages

Maybe you are looking for