Re: Export didn't compress my tables?

Despite the fact that COMPRESS=Y is the default for EXPort, i wonder if anyone can come up with a justification for ever accepting it.

What does it buy you? On IMPort, if the table needs to be created, it'll create the table with an initial extent big enough to hold all the data. Personally, i don't think that's so hot. For one thing, that doesn't take into account any storage management strategies you have in place (i.e. extent sizes in power increments of your block size). More serious is the possibility that you don't enough contiguous space to fit a huge initial extent (in the most extreme case, you won't be able to import even if you pre-create the table specifying smaller extents). And to add insult to injury, the initial extent isn't just as big as the table at the time it was exported, but it's as big as the table ever was (remember, extents don't get deallocated when rows are deleted). You could end up allocating tons o space for just a few rows. Import doesn't care one bit (you didn't think i could go this far without a pun, did you?).

What's the worst that could happen if you specify COMPRESS=N? Your data might not fit into one extent. Personally, i'd rather stick to my strategy than worry about getting everything into 1 extent. My performance will be better. Besides, i spent all that time setting up my space. Why would i want some silly tool to screw it up?

Hey, these are just my opinions from my experiences. If anyone out there knows of a real benefit to accepting COMPRESS=Y, i'd love to hear it.

Barry Received on Mon May 16 1994 - 22:43:26 CEST