在执行exp的时候，要特别的注意，如果没有明确指出，默认compress=y，这个参数的意思就是说在将来imp的时候，将如今要被export的segment的所有extents都加到一起，计算出来所有extents的大小，作为将来imp的表的initial extent的大小。
也就是说imp不能决定新表的initial extent的大小，而是在exp的时候就已经确定了。
所以，这个参数默认值是很糟糕的，在exp的时候需要特别指明compress=n。
为什么很糟糕？因为我想首先表的initial extent要么很小64K（system-managed LMT），要么就每个extent都一样（uniform extent size LMT），一旦initial extent很大，浪费空间（因为起先表的每个extent并不一定写满），imp的表可能比原先的表大，所以有可能在exp的时候造成空间不够的这个现象；另一个缺点就是这个太大的空间对将来的重用表现的不好。
Could you explain the export processing for COMPRESS option ?
According to Oracle document, this manage the initial extent for table data.
Since Oracle 816 and up, if we use the locally management tablespace method,
The INITIAL and NEXT size are the same, what compress will do, and
Which option should we use ? The default is ‘Y’.
Could you elaborate this option please.
1. If we choose default value ‘Y’, when import into another DB, what impact to
the new DB tablespace storage setting?
2. If we choose value ‘N’, what impact when import into another DB.
Assume DB1 tablespace A is using EXTENT MANAGEMENT LOCAL UNIFORM SIZE 64K
the new DB2 tablespace is using the same storage setting. or
3. If I use the larger uniform size, ie 128K.
Followup:
I do not like compress=y. Totally wish it did not exist.
Compress will do what it always did. sum up the existing extents and ask for
that much space. When you import, the LMT will look at your initial request,
divide by its extent size and give you that many extents.
1) it’ll cause you to allocate lots of extents up front in order to satisfy the
compress=y. Eg: if the existing table has 50m allocated to it and you exp with
compress=y — the initial will be 50m. If you import into an LMT with 1meg
extents — it’ll allocate 50 of them initially.
2) it’ll look at the initial and do the same as #1 but the initial will be
smaller then in #1 so it’ll allocate less extents.
3) same as two
既然这么糟糕为什么oracle还要把compress=y作为默认的参数，而不是把compress=n作为默认的参数呢？
因为这是一个历史的遗留问题（legacy）。因为在当时，每个表并不是可以无限的extents，而必须在121个extents以内，所以这就带来了问题。如果表大的超过这些extents怎么办？那就只能使用exp compress=y的办法，先把原来的表导出，然后再imp。这样下来，原来比如有120个extents，imp后就只剩下一个extent了，这个extent的大小与原先的120个extent的大小一样大。这样就暂时解决了extents数目马上超过121个extents的上限。
You have said several times you hate compress=Y, and I’m completely agree about
this, but why is the default?.Is the default in 9i aswell?
Thanks
Pablo R.
Followup:
It’s a hold over from the really olden days — before unlimited extents. When
2k blocks ruled and there was a hard limit of 121 extents/object — the major
number one use of export was to “compress” a table down into fewer extents as it
got close to this number.
It’s a legacy
另外i，我做了试验，还有下面提问的网友也作了实验，发现在9iR2的环境下，并不是像上面描述的那样。为什么会这样呢？
原来tom解释说这是因为9iR2和10gR1 ，关于这点，是bug。在10gR2，这点得到了解决。Tom说他多希望这点没有被修改阿。呵呵。
Kinda confused with compress=Y with LMT on 9.2.
I created a table from dba_objects and then exported that table. Prior to
export, the table had 19 (16 - 64k and 3 - 1M) extents. I did an export of just
that table and used the default for compress (compress = Y).
I then did an import with indexfile set and looked at the file created. It has
a create table statement with initial extent set to 64k. I was expecting to see
the create table statement with an initial extent set at 4M based on the theory
that compress = Y will add up the existing extents for the object?
Followup:
9i and 10gr1 seem to be doing that, but 10gR2 is not.
Bummer, a “bug” I truly wish they had not fixed :(
