Re: Indexed Tablespace Fragmentation

"Jonathan Lewis" <jonathan_at_jlcomp.demon.co.uk> wrote in message news:1020099119.8004.0.nnrp-12.9e984b29_at_news.demon.co.uk...
>
> Interesting point, and one that I hadn't thought of.
>
> I would think that the fact that it is an HW enqueue
> is (roughly speaking) coincidental - the problem is
> the time it takes to add an extent when the hwm
> cannot be bumped.
>
> The comparison on an otherwise empty tablespace is
> then between:
> Reading the bitmap from start to next free bit.
> which could be a handful of blocks and a lot
> of CPU down the file
> and
> Hitting the one fets$ block in the c_ts# cluster
> to find the one fet$ row which represents the
> free space left at the end of the tablespace.
>
> I think your comment tells us which one is faster.
>
> Still, as you say, the correct answer is "Don't Do That Then",
> and I would hope that any sensible DBA would have moved
> the guilty object to the correct tablespace before it got to
> more than a couple of hundred extents.

<disclaimer: well you did say sensible DBA />

I'll live with up to (say) 1000 extents in an lmt (though truthfully more than 300 or so gets my goat). I guess I'm saying a couple of hundred seems conservative.

--
Niall Litchfield
Oracle DBA
Audit Commission UK