Oracle FAQ Your Portal to the Oracle Knowledge Grid

Home -> Community -> Mailing Lists -> Oracle-L -> Re: DBMS_REPAIR package usage

Re: DBMS_REPAIR package usage

From: yong huang <>
Date: Fri, 23 Mar 2001 16:27:29 -0800
Message-ID: <>

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



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

PL/SQL procedure successfully completed.

SQL> print



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. Maybe Jeremiah Wilton can give a better answer.

Yong Huang

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 n
ot 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 th
e 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?



Do You Yahoo!?
Get email at your own domain with Yahoo! Mail.
Please see the official ORACLE-L FAQ:
Author: yong huang

Fat City Network Services    -- (858) 538-5051  FAX: (858) 538-5051
San Diego, California        -- Public Internet access / Mailing Lists
To REMOVE yourself from this mailing list, send an E-Mail message
to: (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L

(or the name of mailing list you want to be removed from). You may
also send the HELP command for other information (like subscribing).
Received on Fri Mar 23 2001 - 18:27:29 CST

Original text of this message