Re: fragmentation issues

Howard J. Rogers allegedly said,on 29/05/2004 6:16 PM:

> It has never been an issue if a segment's extents are all over the place
> 'inside' a tablespace. (You might go back a few versions earlier than me, so
> maybe I should never say never).

No, I don't think it ever was. Even in the days of V4, I don't recall it being an issue. Compared to MANY other problems that existed back then. Mind you, in single disk single user systems it COULD be construed as a problem if all you had was one table. But even back then that was rarely the case...

> The issue is also known by some as the
> 'contiguity of extents' problem. Something you can never (!) achieve
> physically on a file system however hard you try.

Bingo! It always bugged me why people talked about contiguity of Oracle extents without mentioning all the other paraphernalia that introduces wild variations in any measurement. There was a "benchmark" floated around in Australia for a LONG time that claimed without the slightest doubt that "one extent was faster than even two". Done in VMS! I can't even start to count the hours that DBAs here wasted, laboriously keeping everything within one extent, as a result of that doc...

>
> I'm slightly concerned at your use of the phrase "previously called
> extents". Last time I looked, they still were. DBA_CHUNKS anyone?

As in DMT extents. I'm not sure we should still call the LMT allocations "extents"? Are they? Come to think of it: is it still correct to use the term "extent" with LMT? I know it's there, but an extent with LMT can be made up of non-contiguous allocations of the LMT allocation size. Those may not necessarily be contiguous. While the term extent traditionally implied a contiguous allocation of space. Am I explaining myself well here?

(DBA_CHUNKS is new to me?)

-- 
Cheers
Nuno Souto
wizofoz2k_at_yahoo.com.au.nospam