block corruption in 8i standby database

From the past one week I am facing the block corruption problem in my standby database.

Problem description :

Database : orcle8i stanby database
OS : sun solaris 2.8
oracle : oracle8i (8.1.7.2.0)

When I have extracted the live database and before mounting the database if i run the dbv (dbverify) there are no data block corruption.

But after I have refreshed with standby control file and applied archive log files, then if i run the dbv I am getting the block corruption to the data files as

DBVERIFY - Verification starting : FILE = /itmsfx7/itfxdata/itfxidx07.dbf
Block Checking: DBA = 302020051, Block Type =
Found block already marked corrupted
Block Checking: DBA = 302020052, Block Type =
Found block already marked corrupted
Block Checking: DBA = 302020053, Block Type =
Found block already marked corrupted

The hardware engineer has run the fsck for all the filesystem and found that there is no block corruption.

Unable to diagnosis why the oracle is showing the block corruption after the logs are applied.

The extraction is done as follows :

tar -xvbf 126 /dev/rmt/1cbn .

because the backup is taken as

tar -cvbf 126 /dev/rmt/1cbn

Is this having any impact?

We have tested with normal extraction and as well as above extraction type also. Still the problem exists.

Can any one through light on this problem?

Are you getting an error during export also. As export catch a block corruption. If not then may be you need some patch.

At the live server no error at the time of export.

This block corruption is showing any after the log files are applied.

If we check the database after restoration and before log applying there is no block corruption. It is showing only after log applying.

Is this corruption comes under soft or hard corruption.

Is there any other method to find exactly what is causing this error.
Is it OS, oracle or any hardware problem?

DBV checks Oracle datafiles to ensure that:
- The datafile has a valid header.
- Each datablock in the file has a special "wrapper" which
identifies the block - this "wrapper" is checked for correctness.
- DATA (TABLE) and INDEX blocks are internally consistent.

Since your Standby Database is runing in Mount mode just after applying the redologs there may be possiblity datafile's blocks take times to wrapp up and thus causing dbv to throw an error. Not sure though Pls check with Oracle.

I donot think it require redologs when the database is in recovery mode.

I have activated the standby database and checked for the errors in alert log but no errors. the database is opened successfully. I have taken export of the database. Export completed without warnings.

Because the export will give errors if any block corruption present at OS level.

I am able to login to the database through the application menu.

But when I am running some batch files which will do insertion into the tables and indexes respectively. I came across the data block corruption errors as follows.

ORA-20003: ORA-20003: ORA-01578: ORACLE data block corrupted (file #58, block # 20443)
ORA-01110: data file 58:
ORA-26040: Data block was loaded using the NOLOGGING optionaccnt_deal_blncs_a - Insert
ORA-06512: at "I

If the data block corrpution is present at recovery database, then it should also be present at live database.

Where as the live database is not having any block corruptions (checked with export and dbverify ).

Now the question is why the blocks are getting marked as corrupt only at standby database. And how to overcome this problem.

http://metalink.oracle.com/metalink/...&p_id=150694.1

FYI you must not use NOLOGGING opeations if you wanna propagate changes from your primary database to your standby database

Reason :
Database intentionally marks blocks corrupt during a recovery involving a nologging operation, it is because of this that we find corrupted blocks in sequence.
Suggestions :
If we want to find the exact file id and block number using the logfile then we would need to convert the number available as e.g. DBA = 277079327 to Block number and file ID. This can be identified using the dbms_utility package.
To Identify the File ID : dbms_utility.data_block_address_file(results);
To Identify the Block No. : dbms_utility.data_block_address_block(results);

Metalink Referance Note : Doc ID: Note:139425.1

Thanks everybody.

I have got the solution. I found that there are few indexes
in the primary database with nologging option. Due to which
the data block corruption is occuring at DR site.

I have informed accordingly to the primary database sysadmin
to change.

this call can be considered as closed.