Hi, Winnie,
How did you find the file# to be 9 (unless you messed with your original error
message)?
I suggest you post your message to news:comp.databases.oracle.server (or
http://news.interbulletin.com/cgi-bin/ibwrn/post/comp.databases.oracle.server
if your company doesn't have a news server). Hopefully it will attract
attention of Jonathan Lewis, the Oracle 8i expert, and several (former) Oracle
employees such as Kyle Hailey, Howard Rogers and Anjo Kolk. The good thing
about that newsgroup is nobody is audacious enough to post spam messages like
"tomorrow I'll post the chocolate recipe here".
Yong Huang
yong321_at_yahoo.com
- Winnie_Liu_at_infonet.com wrote:
>
>
> Yong,
>
> Thanks a lot for all the research! :D
>
> The file# that actaully contains this block is 9. My database is not that
> big at all.
>
> I did do some research myself and some Oracle analysts in the World Wide
> Support does suggest that the influxed blocks are very likely to be a
> fractured block. But I reallly have no idea how it got in there... .
>
> Winnie
>
>
>
>
>
> yong huang <yong321_at_yahoo.com> on 03/23/2001 04:01:21 PM
>
> To: oracle-l_at_fatcity.com
> cc: Winnie_Liu_at_infonet.com, yong321_at_yahoo.com, jeremiah_at_wolfenet.com
>
> Subject: 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
>
>
> __________________________________________________
> Do You Yahoo!?
> Get email at your own domain with Yahoo! Mail.
> http://personal.mail.yahoo.com/
>
>
>
>
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail.
http://personal.mail.yahoo.com/
--
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-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 Sat Mar 24 2001 - 07:29:48 CST
