Re: Importing a compressed table doesn't go to smallest suitable free space

From: Norm LeBlanc <chicnorm_at_norm.inforamp.net>
Date: 1996/02/19
Message-ID: <4ga4qt$rlm_at_sam.inforamp.net>#1/1


Ken Friday (ken.friday_at_teldta.com) wrote:
: chicnorm_at_norm.inforamp.net (Norm LeBlanc) wrote:
: >I am trying to import a table that I had previously exported with the
: >compress extents option and I am expecting it to be placed in the
: >smallest available contiguous block of free space that it will fit in.
: >But this does not happen. Am I expecting too much?
: >
: >Dinesh Fernandopulle
: >
: >
: My understanding of "compress extents" is that the initial extent storage
: parameter is set equal to the sum of existing extents allocated. It does
: not adjust for actual data volumes.
 

: Ken F.
 

: --
 

: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

I want it to use the sum of the previous extents. But if the sum is 2M, I want it to use an available space of 2.5M, 3M, or 4M say, without going and using 2M of an 8M free space leaving a 6M chunk. The funny thing is it does the above for a table, and another table I might try the same procedure of defragmenting on, fits nicely into a 2.1M contiguous block of free space, without going to that 6M chunk that was left behind!!

By the way I am using DBA_FREE_SPACE to verify the sizes of contiguous chunks of free space.

Dinesh Received on Mon Feb 19 1996 - 00:00:00 CET

Original text of this message