今天刚上班，一个朋友问我“我们这边有个表空间扩大到，1.4T，但是删除数据没有用，这个都不变小?”。
我给他这样解释了下
"这个数据文件；你删除数据是不会影响到它的大小；可以这样理解；这个数据文件相当于一个水桶；这个水桶的大小是1.4T；删除数据这个操作相当于把里面水抽出来。 水桶的大小是不变的；水是变少了。水桶可用的空间变大了；可以装更多的水。"
想一个表空间扩张到1T多。有下面两种可能
1. 真的有怎么多的数据量的业务。
2. 这表空间一定是设置为自动扩张的；导致数据文件暴涨；其中里面有99%的数据是无用数据；可以清理的。这是没有维护好。
那有没有办法减少这个数据文件呢？办法是有：就‘alter database datafile '****.dbf' resize ***G’;
可行吗？这个还是需要根据当时服务器环境来判断？
第一步：看下该表空间的使用情况
SELECT a.tablespace_name "表空间", a.bytes / 1024 / 1024 "表空间大小(M)", (a.bytes - b.bytes) / 1024 / 1024 "已使用空间(M)", b.bytes / 1024 / 1024 "空闲空间(M)", round(((a.bytes - b.bytes) / a.bytes) * 100, 2) "使用比"FROM (SELECT tablespace_name, SUM(bytes) bytes FROM dba_data_files GROUP BY tablespace_name) a, (SELECT tablespace_name, SUM(bytes) bytes, MAX(bytes) largest FROM dba_free_space GROUP BY tablespace_name) bWHERE a.tablespace_name = b.tablespace_nameORDER BY ((a.bytes - b.bytes) / a.bytes) DESE;
截图情况为：大约使用了250G;那就是不是可以resize到500G；减少了700G的磁盘空间呢？下面继续判断
我让她执行 select file#,name from v$datafile; 找到对应的文件号是多少？答案是9。
继续执行 select max(block_id) from dba_extents where file_id=9；
select file#,name from v$datafile;select max(block_id) from dba_extents where file_id=9；
已经写到175382656块了。我当时凌乱了；换算为T；175392656*8/(1024*1024*1024)=1.3T;结果约为1.3T；看来用‘alter database datafile '****.dbf' resize ***G’并不可行。
若不明白；就以刚刚距离的水桶来解释：
刚刚那个水桶是1.4T； 里面放了260G的水；但这些水并不是连续放置的；水也不是直接放到水桶里面的；水是放在里面的空槽；空槽的理解相当于oracle中的段（可以理解为表，索引）；现在是有一个空槽放到1.3T的位置； 现在我想压缩这个水桶；我只能压缩到1.3T 的位置；
最后：
1. 用逻辑备份这个数据文件；在删除表空间；重新建一个表空间；在进行导入；但是不建议操作；1.4T的数据文件；备份/还原是项巨大的工程；操作时该业务还需要停到。
2. 我建议还是不动为好；目前那个表空间有1.4T；只用了260G；意思是说目前不会有磁盘扩张的可能性。 那个/data1目录下还有90G可用；足够了。把所有的表空间都取消自动扩张。好好维护下。