Re: Q:Table Fragmentation. How do I reduce it?

Exactly.

But the problem is most people don't get the sizing aspects right in the first place, and that's how they end up with objects that have many, many extents, and of various sizes - both inter and intra object. Objects with a huge number of extents usually point to a more fundamental design problem.

And some people look at imp/exp as a way out of the problem, which of course it isn't.

It was that aspect of the original post (can't remember who wrote it) that I really picked up on, that "imp/exp with or without compress=y makes no real difference". It does, especially on a well designed database.

Cheers,

Steve Phelan.

>Connor McDonald wrote in message <350F9E1D.2C58_at_bhp.com.au>...
>Point taken but don't you agree that you things you mention
>are essentially about getting you extent SIZING correct as opposed
>to the NUMBER of extents...
>
>eg (say) 8k blksize, db_mul...count = 8 and IO buffer limit of 64k at
>the OS, then any reasonable extent size that is a multiple of 64k
>is going to give identical (full scan) read performance, simple because
>all full scan reads will be done in multiples of 64k anyway...
>
>Conversely any extent size that is not an appropriate multiple will
>impact performance...
>
>Maybe it is just a semantics thing...
>
Received on Wed Mar 18 1998 - 00:00:00 CST