Re: Space Management w/ LMTs

Noons wrote:
> NetComrade apparently said,on my timestamp of 8/04/2005 8:25 AM:
>
>
> > Was looking for something more specific, like this:
>
> Know what you mean, but one could argue that this:
>
> > decode(allocation_type, 'UNIFORM',
> > dfs.free_space/dt.next_extent) uniform_extents_avail,
>
> is not really relevant anymore with LMT. Although of course
> you might still want to use next_extent and initial_extent,
> the whole idea with LMT is to throw away all that concern.
> Just use LMTs of suitable uniform extent size and place
> the objects accordingly: bingo, no more worries.
> Other than bugs, of course... ;)

And the ocassional misfeature. For example, if you use compress=N with export, together with the query statement to get a subset of the data, on a table with a large initial_extent in LMT, and then import it to new instance also LMT, it makes the table the size of the original table (8 through 9206). And the only way around this seems to be to pre-create the table in the new instance. Not a big deal if there's only one table, but with hundreds and associated constraints it gets tedious. One would think one could either tell exp/imp not to do that, or be able to update initial. Or did I miss something obvious? The utilities guide on compress documents the behavior correctly. It's just silly behavior with the query option, and kind of odd on its own, since there's no way to just say "use up the amount of space the data actually needs" or reasonably ask "do I have enough free space to import?"

jg

--
@home.com is bogus.
Only one kid?  Must be Canadians:
http://www.signonsandiego.com/uniontrib/20050410/news_1n10signs.html