Re: dbv - Found block already marked corrupted

Mike,
Excellent analysis!  I agree that the block is likely allocated to a segment
but has not yet been used by the segment in question.  That is, it resides
"above" the segment's "high-water mark"...

You can find out for certain (if the segment is in a "freelist-managed"
tablespace, i.e. SEGMENT_SPACE_MANAGEMENT = 'MANUAL') by calling the
DBMS_SPACE.UNUSED_SPACE procedure on the segment.  Three of the OUT
parameters returned are:

    last_used_block
    last_used_extent_file_id
    last_used_extent_block_id

I've attached source for a PL/SQL stored procedure that makes using the
DBMS_SPACE packaged procedures a little easier.  I don't have it posted on
www.evdbt.com yet, but I'll get it done soon...

One further question, though...

>> Of course, if someone knows a utility to un-flag a block I'm all ears.

Why would anyone want to "unflag" a block that has been flagged as corrupt?
I'm all ears for that...  :-)

-Tim



on 1/30/04 9:14 AM, Hately, Mike (LogicaCMG) at mike.hately@xxxxxxxxxx
wrote:

> Hi,
> corruptions of this kind can be caused by recovery operations that 'roll
> through' operations that were performed as NOLOGGING. This is because Oracle
> can't be sure that the object was not changed so the blocks are marked as
> corrupt. 
> It may be that the blocks in question are not actually in use by the object
> even though they are allocated to it. If this is the case they'll be
> formatted when they're eventually used.
> Oracle considers that these blocks are not in use and for that reason it
> reports a message and does not increment the "Pages Failing" statistics
> produced when dbv completes.
> I don't know of a way to corect this problem without recreating the object
> (which would certainly fix the messages). As you've already found, the
> object itself is not corrupted so the only problem is the spurious messages.
> It's up to you whether you think an ALTER TABLE MOVE is worth the hassle
> just to fix those messages.
> Of course, if someone knows a utility to un-flag a block I'm all ears.
> 
> Cheers,
> Mike Hately
> 
> -----Original Message-----
> From: Kaing, Leng [mailto:Leng.Kaing@xxxxxxxxxxxxxxxx]
> Sent: 30 January 2004 06:05
> To: oracle-l@xxxxxxxxxxxxx
> Subject: FW: dbv - Found block already marked corrupted
> Importance: High
> 
> 
>> Hi Guys,
>> =20
>> Sorry if this is covering old grounds... I ran dbv against our =
> datafiles and it came back with this:
>> =20
>> Found block already marked corrupted
>> Block Checking: DBA =3D 29363614, Block Type =3D
>> Found block already marked corrupted
>> Block Checking: DBA =3D 29363615, Block Type =3D
>> =20
>> I then ran cdba and converted it to fileid and blockid, analyzed the =
> table validate structure cascade and there was nothing wrong. Metalink =
> suggests that I need to recreate the object to get rid of the error. Is =
> this the only way? Is there a dbms_repair or something that we can do to =
> unmark an already marked corrupted block?
>> =20
>> TIA,
>> =20
>> Leng.
>> =20
>> ----------------------------------------------------------
>> Leng Kaing
>> Email: leng.kaing@xxxxxxxxxxxxxxxx
>> Phone: +61-3-9203-7589
>> Mobile: +61-417-371-348
> 
> 
> ******************************************************************************
> **************
> E mail Disclaimer
> 
> You agree that you have read and understood this disclaimer and you agree to
> be bound by its terms.
> 
> The information contained in this e-mail and any files transmitted with it (if
> any) are confidential and intended for the addressee only.  If you have
> received this  e-mail in error please notify the originator.
> 
> This e-mail and any attachments have been scanned for certain viruses prior to
> sending but CE Electric UK Funding Company nor any of its associated companies
> from whom this e-mail originates shall be liable for any losses as a result of
> any viruses being passed on.
> 
> No warranty of any kind is given in respect of any information contained in
> this   e-mail and you should be aware that that it might be incomplete, out of
> date or incorrect. It is therefore essential that you verify all such
> information with us before placing any reliance upon it.
> 
> CE Electric UK Funding Company
> Lloyds Court
> 78 Grey Street
> Newcastle upon Tyne
> NE1 6AF
> Registered in England and Wales: Number 3476201
> 
> ******************************************************************************
> **************
> 
> ----------------------------------------------------------------
> Please see the official ORACLE-L FAQ: http://www.orafaq.com
> ----------------------------------------------------------------
> To unsubscribe send email to:  oracle-l-request@xxxxxxxxxxxxx
> put 'unsubscribe' in the subject line.
> --
> Archives are at http://www.freelists.org/archives/oracle-l/
> FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
> -----------------------------------------------------------------



-- Binary/unsupported file stripped by Ecartis --
-- Type: application/octet-stream
-- File: space_usage.sql


----------------------------------------------------------------
Please see the official ORACLE-L FAQ: http://www.orafaq.com
----------------------------------------------------------------
To unsubscribe send email to:  oracle-l-request@xxxxxxxxxxxxx
put 'unsubscribe' in the subject line.
--
Archives are at http://www.freelists.org/archives/oracle-l/
FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------

Other related posts: