imp方式還原資料庫空間佔用特別大

今天在資料庫上透過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);

結果發現統計資訊是更新了，資料表所佔空間還是沒有被釋放。