Re: dbv - Found block already marked corrupted

From: Tim Gorman <tim_at_sagelogix.com>
Date: Fri, 30 Jan 2004 13:46:04 -0700
Message-ID: <BC40109E.F6C9%tim@sagelogix.com>

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_at_nedl.co.uk 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_at_team.telstra.com]
> Sent: 30 January 2004 06:05
> To: oracle-l_at_freelists.org
> 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_at_team.telstra.com
>> 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_at_freelists.org
> 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_at_freelists.org 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
-----------------------------------------------------------------

Received on Fri Jan 30 2004 - 14:46:04 CST