Hi, Winnie,

Just a little more research. I wonder how you can have an rdba that big,
0x24070020, which is 604438560 in decimal.

SQL> var a number;
SQL> exec :a := dbms_utility.data_block_address_file(604438560);

PL/SQL procedure successfully completed.

SQL> print

        A
---------
      144

SQL> exec :a := dbms_utility.data_block_address_block(604438560);

PL/SQL procedure successfully completed.

SQL> print

        A
---------
   458784

This is done on 8.1.6. It says the block is in file 144, block 458784. Why does
your error say file=0? Anyway, in case you do have a file numbered 144, check
to see if there's an object there. If it's indeed file 0, the dba should be the
same as block#, 458784, or 0x70020. DBMS_UTILITY.MAKE_DATA_BLOCK_ADDRESS can
confirm this. However, that file# 0 may be just an indicator that that
information is lost, as multiple other 0's look like.

I believe dbv reports an error when it encounters a fractured block, i.e., the
first two bytes of tail (0003 in your case) does not match the last two bytes
of rdba (0020). We know how a fractured block is created during hot backup. But
I don't understand why an offlined datafile (as you said in another email) can
contain fractured blocks.

Yong Huang
yong321 AT yahoo.com

you wrote:

I have a datafile in my production box (a user data tablespace), when I run
dbv against it, it showed that 5 blocks are "influxed"

Page 458784 is influx - most likely media corrupt
***
Corrupt block relative dba: 0x24070020 file=0. blocknum=458784.
Fractured block found during dbv:
Data in bad block - type:0. format:0. rdba:0x00000000
last change scn:0x0000.00000000 seq:0x0 flg:0x00
consistancy value in tail 0x0003c204
check value in block header: 0x0, check value not calculated
spare1:0x0, spare2:0x0, spare2:0x0

We can copy this file to tape, dd this file. On the OS disk level, the OS does
not treat this as corrupted. But it is corrupted on the oracle (software) level.

I've checked and can't find any object associate with these 5 corrupted blcok.

That means that there is no data inside those blocks.

Since the tablespace is about 12 GB on a highly active system (which only got 3
hours maintance window each month), export/import (then drop the tablespace)
which Oracle support suggested is mostly out of the question. (Especially, it
is very hard for me to convince the sysadmin that the blocks are
corrupted as they don't see any I/O error associate with this file and the
developers don't see any problem with the application either!)

I am currently thinking about upgrading this database to 8.1.6 to make use of
the DBMS_REPAIR package to make those blocks as "unusable". But I
am not sure that if the DBMS_REPAIR package can run against the blocks which do
not belong to any objects!! Can someone  give me some guidences?

thanks

Winnie