| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Mailing Lists -> Oracle-L -> Re: DBMS_REPAIR package usage
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. Maybe Jeremiah Wilton can give a better answer.
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
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?
thanks
Winnie
-- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: yong huang INET: yong321_at_yahoo.com 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: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-LReceived on Fri Mar 23 2001 - 18:27:29 CST
(or the name of mailing list you want to be removed from). You may
also send the HELP command for other information (like subscribing).
 |
 |