Wrong initial extent in XXX_SEGMENTS for LMT. Minor annoyance, will oracle ever fix this ?

I know it's probably not THAT important, but who knows ?

When you create a table or an index in a locally managed tablespace, and you specify an INITIAL extent, oracle ignores the initial extent parameter, and depending wether the locally managed tablespace extent allocation is autoallocate or uniform, you end up with a number of extents to accomodate the size you specified.

The problem is that in the INITIAL_EXTENT you find when you query DBA_SEGMENTS is the one you specified, but if you look at the actual extents, you'll notice that the initial extent is NOT what you specified.

With the NEXT extent, it's not really a problem, it is simply ignored.

Normally, when you create an object in a locally managed tablespace, you simply omit the extent clauses and you end up with the correct values in initial and next (next, in the case of autoallocate tablespaces)

But when you import tables from dictionary managed tablespaces (or probably tables exported witht he compress=y, default option) into a locally managed tablespace, you have lots of discrepancies between the actual extent sizes and the initial extent reported by DBA_SEGMENTS.

Why don't they fix the import utility so that it drops the "INITIAL" parameter when it encounters a locally managed tablespace ?

It's not DANGEROUS per se, but it would make things clearer. I mean, you might have some sort of script that does some processing according to the initial extent of objects as determined from DBA_SEGMENTS, and in this case, it would have incorrect input to work on.

I see no easy way of fixing that sort of import problems other than pre-creating the tables before import, without specifying any extents clauses (A pain in the lower back) or simply live with it. Received on Thu Apr 08 2004 - 14:45:36 CDT