Re: Why is NEXT_EXTENT changing all the time?

Daniel A. Morgan <dmorgan_at_exesolutions.com> wrote in message news:3A71149F.F654C7DC_at_exesolutions.com... {snip]
> > This is terrible advice, sorry Daniel (and I do try to be reasonable
 most of
> > the time). Your initial extents will be largely fresh air for much of
 your
> > three years, and you are practically guaranteeing fragmentation... As
 one
> > who has shares in Seagate, perhaps I should encourage you to keep up the
> > good work! But apart from anything else, if you look which way the wind
 is
> > going, by about Oracle 10 (OK, maybe Oracle 15) you won't even be able
 to
> > specify odd extent sizes -locally managed tablespaces with uniform
 extent
> > sizes clearly being the path that Oracle is mapping out for the future.
>
> First off it is impossible for it to cause fragmentation. An extent is
 part of a
> single segment and can not be part of multiple segments. In fact it is
 only the
> creation of multiple extents, and their subsequent emptying that can cause
> fragmentation.
>

Yes, I know that Daniel... but what you're telling me is that you never truncate, never drop and never move segments to other tablespaces? Really? You've purposely *set up* a situation where any one of those things happening will result in fragmentation. *That* was my point.

> With respect to wasted DASD you are correct. Lots of it. For the first
 month.
> Less for the second. And none by the end of the designated period. But
 DASD is
> cheap when compared to the cost of a DBA having to go in and defragment,
> reorganize tablespaces, and do all the other things that are later
 required. I
> know my billing rate and you can buy a lot of disk array for the cost of
 me
> doing that work.
>

What's the problem with fragmentation? A nasty one of segments not being able to extend, yes. But also one of wasting disk space. What's the problem with your proposed solution? Er, wasted disk space, and stacks of it. At the end of three years, OK the thing is using its designated space efficiently. But until that time, huge swathes of the disk are lying around doing nothing, and incapable of being used for anything else.

Frankly, on the assumption that your time is too expensive, they'd be better off buying 300 more hard disks and letting the thing rip. Why bother defragmenting? -Just buy a new hard disk!

I think the point is that if you do a minimum of planning and organisation work up front, there will be *no need* to defragment or re-organise the tablespaces -and at the core of that planning and organisation is the setting up of appropriate tablespaces, each with consistent extent sizes.

HJR
> Daniel A. Morgan
>
Received on Fri Jan 26 2001 - 03:59:00 CST