exp之compress到底在压缩什么
来源:互联网 发布:英雄无敌7 for mac 编辑:程序博客网 时间:2024/05/01 14:35
exp之compress到底在压缩什么
之前有同事问我compress导出的时候可以压缩多少比例,可以压缩成什么格式的。唉,想当初我也是这么认为的,其实这个参数的作用是在导入过程中创建表的时候,初始的INITIAL_EXTENT设置。
compress默认值是Y,也就是说在创建表的时候会建立一个包含所有数据块容量的初始extent,该参数只在导出的时候有效,导入的时候无效(其实你如果加上该参数会报错)。
具体看下面例子。
首先是导出之前的表的信息:
SQL> Select segment_name,bytes/1024,blocks,Extents,initial_extent From user_segments;
SEGMENT_NAME BYTES/1024 BLOCKS EXTENTS INITIAL_EXTENT
--------------------------------------------------------------------------------- ---------- ---------- ---------- --------------
T1 704 88 11 65536
做一个默认的compress=y导出之后,重新导入之后表的信息:
SQL> /
SEGMENT_NAME BYTES/1024 BLOCKS EXTENTS INITIAL_EXTENT
--------------------------------------------------------------------------------- ---------- ---------- ---------- --------------
T1 704 88 11 720896
再做一个compress=n导出之后,重新导入之后表的信息:
SQL> /
SEGMENT_NAME BYTES/1024 BLOCKS EXTENTS INITIAL_EXTENT
--------------------------------------------------------------------------------- ---------- ---------- ---------- --------------
T1 704 88 11 65536
具体的也可以在创建表的dml中看到差异:
-- Create table
create table T1
(
id NUMBER(4),
name VARCHAR2(4)
)
tablespace STORE1
pctfree 10
initrans 1
maxtrans 255
storage
(
initial 704K
minextents 1
maxextents unlimited
);
-- Create table
create table T1
(
id NUMBER(4),
name VARCHAR2(4)
)
tablespace STORE1
pctfree 10
initrans 1
maxtrans 255
storage
(
initial 64K
minextents 1
maxextents unlimited
);
其实这里还可以解答一个疑惑:为什么我的一个表明明没有数据,但是在导入的时候执行了很长时间,其实就是这个参数在作怪,通常由于频繁的insert、update然后delete表之后,这个表的extent参数还是没有该表,还是维持在当初扩展到最大的值,因此在导入创建表指定extent的时候耗费了大量时间。
-The End-
之前有同事问我compress导出的时候可以压缩多少比例,可以压缩成什么格式的。唉,想当初我也是这么认为的,其实这个参数的作用是在导入过程中创建表的时候,初始的INITIAL_EXTENT设置。
compress默认值是Y,也就是说在创建表的时候会建立一个包含所有数据块容量的初始extent,该参数只在导出的时候有效,导入的时候无效(其实你如果加上该参数会报错)。
具体看下面例子。
首先是导出之前的表的信息:
SQL> Select segment_name,bytes/1024,blocks,Extents,initial_extent From user_segments;
SEGMENT_NAME BYTES/1024 BLOCKS EXTENTS INITIAL_EXTENT
--------------------------------------------------------------------------------- ---------- ---------- ---------- --------------
T1 704 88 11 65536
做一个默认的compress=y导出之后,重新导入之后表的信息:
SQL> /
SEGMENT_NAME BYTES/1024 BLOCKS EXTENTS INITIAL_EXTENT
--------------------------------------------------------------------------------- ---------- ---------- ---------- --------------
T1 704 88 11 720896
再做一个compress=n导出之后,重新导入之后表的信息:
SQL> /
SEGMENT_NAME BYTES/1024 BLOCKS EXTENTS INITIAL_EXTENT
--------------------------------------------------------------------------------- ---------- ---------- ---------- --------------
T1 704 88 11 65536
具体的也可以在创建表的dml中看到差异:
-- Create table
create table T1
(
id NUMBER(4),
name VARCHAR2(4)
)
tablespace STORE1
pctfree 10
initrans 1
maxtrans 255
storage
(
initial 704K
minextents 1
maxextents unlimited
);
-- Create table
create table T1
(
id NUMBER(4),
name VARCHAR2(4)
)
tablespace STORE1
pctfree 10
initrans 1
maxtrans 255
storage
(
initial 64K
minextents 1
maxextents unlimited
);
其实这里还可以解答一个疑惑:为什么我的一个表明明没有数据,但是在导入的时候执行了很长时间,其实就是这个参数在作怪,通常由于频繁的insert、update然后delete表之后,这个表的extent参数还是没有该表,还是维持在当初扩展到最大的值,因此在导入创建表指定extent的时候耗费了大量时间。
-The End-
- exp之compress到底在压缩什么
- 使用split、compress分割压缩oracle的exp文件
- 到底在痛什么?
- exp、imp compress=y
- web前端之HTML5压缩图片compress image with canvas
- bitmap 压缩 compress
- 销售到底在销售什么?
- 我到底在追求什么?
- 人生到底在追求什么
- 到底在坚持什么呢?
- 我到底在怕什么
- 我们到底在定制什么
- 传智播客到底在坚持什么?
- EXP的compress=Y参数含义
- common-compress压缩解压文件
- android compress 压缩 会不会失真
- Apache Commons Compress 压缩zip
- 人的一生,到底在追求什么?
- hibernate 数据库关键字处理
- 想和你去吹吹风
- redis的五种类型(二)
- signed char*/unsigned char*/QString
- 黑马程序员-银行业务调动系统
- exp之compress到底在压缩什么
- navigationController视图间的跳转
- 图像叠加
- IHttpHander讲解
- complie and install open-iscsi
- JPYPE用户手册小译
- 自定义HTTPHandler实现数字水印效果
- Vertex Shader - 散射光照处理
- DataStage 与PowerCenter