Re: dba_extents slow workaround

From: HansPeter <hans-peter.sloot_at_atosorigin.com>
Date: Tue, 5 May 2009 05:51:18 -0700 (PDT)
Message-ID: <d5d763ca-f762-4a8f-8ab5-1348f21a2c4e_at_s20g2000vbp.googlegroups.com>



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. Received on Tue May 05 2009 - 07:51:18 CDT

Original text of this message