今天在数据库上通过imp的方式导入一个数据库dmp文件，该文件只有80M多点，心想这么小的数据文件应该不需要多大表空间，如是先创建了一个1024M的表空间，结果imp导入发现空间不够，如是再增加1G，再次导入，再次报错。。。增加了好几次，最后干脆一次增加4G，使整个表空间达到10G，终于正常导入了，nnd。

查看日志，所有数据表基本没什么数据，怎么会这么占空间了，如是查看 dba_segments ，看看哪些对象最占空间，发现占空间的都是都是数据库表，可查看对应的导入日志，导入的记录条数却为 0，奇怪，看看该表

select * from dba_tables where tablespace_name = 'ZZ_DB' and table_name='T_STDT';

     OWNER  TABLE_NAME  TABLESPACE_NAME  CLUSTER_NAME  IOT_NAME  STATUS  PCT_FREE  PCT_USED  INI_TRANS  MAX_TRANS  INITIAL_EXTENT  NEXT_EXTENT  MIN_EXTENTS  MAX_EXTENTS PCT_INCREASE FREELISTS FREELIST_GROUPS LOGGING BACKED_UP NUM_ROWS BLOCKS EMPTY_BLOCKS AVG_SPACE CHAIN_CNT AVG_ROW_LEN AVG_SPACE_FREELIST_BLOCKS NUM_FREELIST_BLOCKS DEGREE INSTANCES CACHE TABLE_LOCK SAMPLE_SIZE LAST_ANALYZED PARTITIONED IOT_TYPE TEMPORARY SECONDARY NESTED BUFFER_POOL ROW_MOVEMENT GLOBAL_STATS USER_STATS DURATION SKIP_CORRUPT MONITORING CLUSTER_OWNER DEPENDENCIES COMPRESSION DROPPED
 ZZ T_STDT ZZ_DB VALID 10 1 255 671088640 1048576 1 2147483645 YES N 1471049 158694 0 0 0 368 0 0         1         1    N ENABLED 2000 2014/3/5 17:03:31 NO N N NO DEFAULT DISABLED YES NO DISABLED YES DISABLED DISABLED NO


发现统计信息里面，该表的数据记录数为 100W多，难怪占这么大空间了，如是想到了给它 shrink 空间（这里就不介绍shrink相关话题了）。

alter table zz.T_STDT enable row movement;


alter table zz.T_STDT shrink space cascade;

再次查看该表的占用空间，发现由原来的接近1G缩小到现在的0.3M了，再次查询 dba_tables 该表的统计信息，和前面一样没有变化，如是分析一下该表。

exec dbms_stats.gather_table_stats(ownname => 'ZZ',tabname => 'T_STDT',estimate_percent => 30,degree => 2,cascade => true,force => true);

分析完后，再次查看dba_tables 该表的统计信息
select * from dba_tables where tablespace_name = 'ZZ_DB' and table_name='T_STDT';

    OWNER  TABLE_NAME  TABLESPACE_NAME  CLUSTER_NAME  IOT_NAME  STATUS  PCT_FREE  PCT_USED  INI_TRANS  MAX_TRANS  INITIAL_EXTENT  NEXT_EXTENT  MIN_EXTENTS  MAX_EXTENTS PCT_INCREASE FREELISTS FREELIST_GROUPS LOGGING BACKED_UP NUM_ROWS BLOCKS EMPTY_BLOCKS AVG_SPACE CHAIN_CNT AVG_ROW_LEN AVG_SPACE_FREELIST_BLOCKS NUM_FREELIST_BLOCKS DEGREE INSTANCES CACHE TABLE_LOCK SAMPLE_SIZE LAST_ANALYZED PARTITIONED IOT_TYPE TEMPORARY SECONDARY NESTED BUFFER_POOL ROW_MOVEMENT GLOBAL_STATS USER_STATS DURATION SKIP_CORRUPT MONITORING CLUSTER_OWNER DEPENDENCIES COMPRESSION DROPPED
 ZZ T_STDT ZZ_DB VALID 10 1 255 671088640 1048576 1 2147483645 YES N 0 0 0 0 0 0 0 0         1         1    N ENABLED 0 2014/3/5 17:16:57 NO N N NO DEFAULT ENABLED YES NO DISABLED YES DISABLED DISABLED NO


这次统计信息已更新，记录条数为0.

这样看来，分析一下整个数据库，这些表占用的空间应该也能释放了。

exec dbms_stats.gather_database_stats(estimate_percent => 30,degree => 4,cascade => true);

或者分析对应的schema

exec dbms_stats.gather_schema_stats(ownname => 'ZZ',estimate_percent => 30,degree => 4,cascade => true);

结果发现统计信息是更新了，数据表所占空间还是没有被释放。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/9399028/viewspace-1101753/，如需转载，请注明出处，否则将追究法律责任。