Re: LMT advice

Daniel Morgan wrote:

> I've seen the same thing which is why I am not ready to purchase what
> Howard is selling.

I'm not selling anything, Daniel. But Brian's own figures go to show that autoallocate does not permit fragmentation to happen. Fragmentation being pockets of free space that are the wrong size for some other segment to make use of, Brian's output shows that under the hood, autoallocate is using a consistent 64K extent model, and that if a segment requests a chunk of space of xMB, autoallocate will be able to fit that request into whatever pieces of free space are hanging around, since all of the free space pieces will be 64K-multiples. He has odd-sized extents, sure enough. But they were able to fit into whatever pieces of free space he had lying around. And when they get dropped, something else will be able to make use of that space, too. Brian's figures are actually a nice clincher for the autoallocate smarts.

>In fact the entire
> concept of "scaling up" I interpret as meaning a new name for
> pct_increase and it is what I have observed.

Not so fast. That's an intellectual sleight of hand that can't be allowed to pass without comment. Autoallocate scales up just as pct_increase did, true enough. But pct_increase applied an arbitrary percentage to an arbitrary starting point. It is no wonder that pct_increaase therefore left a complete pig's breakfast of extent sizes within a tablespace, and hence caused fragmentation like crazy. Autoallocate isn't even in the same ball park. It scales up in multiples of 64K, consistently. Since the underlying structure is 64K pieces, fragmentation cannot occur with anything like the ease as pct_increase permitted (and caused).

They aren't the same thing at all, there's no comparison to be drawn between them (apart from the face that they are both attempting to prevent huge numbers of extents from being acquired, which remains a worthy goal).

>
> If I'm worng I'd be happy to be corrected. But my experience with
> UNIFORM extents is that they solve
> every problem I have had.

I agree that uniform sizing is a lovely idea. And I've been very reluctant to endorse autoallocate much before now, because the intracacies of the algorithm are nothing if not opaque, and I don't like recommending things I can't explain or predict very easily. But my conclusion is simply that autoallocate does a very efficient job, and that there is nothing to fear from using it.

I also think that if you look at the direction Oracle is moving in (self-managing database etc etc etc) it is evident that the entire thrust of database design and administration is in the direction of 'hands-off'. Picking an appropriate uniform size is still very much 'hands-on', and unnecessarily so.

With autoallocate, I would suggest that table creation becomes a truly set-and-forget affair, and I think on balance that is a good thing.

Regards
HJR
>And I've never experienced what Sybrand
> describes as being the experience
> related by the instructor.
>
  Received on Fri Sep 26 2003 - 07:54:55 CDT