Re: dba_extents slow workaround
From: Michael Austin <maustin_at_firstdbasource.com>
Date: Tue, 05 May 2009 16:43:29 -0500
Message-ID: <vg2Ml.3650$fD.2529_at_flpi145.ffdc.sbc.com>
HansPeter wrote:
> On 4 mei, 23:39, Michael Austin <maus..._at_firstdbasource.com> wrote:
>
> Well, have you never had to query dba_extents to see in what extent
> and what segment a corrupted block belong?
> I had to do a block dump to get the object id and then search
> dba_objects.
> But it is much easier to see how the extents are allocated using
> dba_extents.
Date: Tue, 05 May 2009 16:43:29 -0500
Message-ID: <vg2Ml.3650$fD.2529_at_flpi145.ffdc.sbc.com>
HansPeter wrote:
> On 4 mei, 23:39, Michael Austin <maus..._at_firstdbasource.com> wrote:
>> HansPeter wrote: >>> On 1 mei, 17:40, Michael Austin <maus..._at_firstdbasource.com> wrote: >>>> Mladen Gogala wrote: >>>>> On Wed, 29 Apr 2009 19:06:15 -0500, Michael Austin wrote: >>>>>> Are you using DMT or LMT? >>>>>> ASM? Raw? Cooked? >>>>> Probably not DMT in 10.2. >>>> Ya never know... I had systems at my previous gig that were upgraded >>>> from 8i->9i->10.2.0.4 and was still using DMT even though I all but beat >>>> them up to get it updated. >>>> - Tekst uit oorspronkelijk bericht niet weergeven - >>>> - Tekst uit oorspronkelijk bericht weergeven - >>> All tablespaces are locally managed on ASM. >> This is the real question I should have asked... what problem are you >> really trying to solve because while LMT uses an "extent" term, its >> definition and usage is very different from that of the traditional >> Oracle definition. The way the Area BitMap and SPAceManagement pages >> work, worrying about extent coalescing is a moot point. Which is one >> reason why some of those traditional tablespace qualifiers are ignored.- Tekst uit oorspronkelijk bericht niet weergeven - >> >> - Tekst uit oorspronkelijk bericht weergeven -
>
> Well, have you never had to query dba_extents to see in what extent
> and what segment a corrupted block belong?
> I had to do a block dump to get the object id and then search
> dba_objects.
> But it is much easier to see how the extents are allocated using
> dba_extents.
Not sure why you would really need to do this... unless you are trying to restore an entire file. I prefer to just get the block from corrupt blocks, feed it into RMAN and let it restore just the corrupt block. It will then perform a recovery to ensure that block had not been updated since last backup. This feature is one of the reasons why coalescing extents is no longer necessary and could potentially screw your backup methods. ie if the blocks were coalesced and moved, they are no longer the same blocks - and redo does not cache this sort of ddl. Received on Tue May 05 2009 - 16:43:29 CDT