请教表空间优化的问题

Question

truncate table test;
或者
drop table test purge;

Answer 1

1、查看表空间对应的数据文件
2、查看对应数据文件上最大的块号（dba_extents）
3、已经块号找到对应的对象名，用DROP或MOVE做处理
4、用select 块号*8k from dual;计算数据文件占用大小
5、alter database ..... resize ...;

Answer 2

直接的清空回收站看看，还是用purge 命令的

Answer 3

1. drop 的表， 可以 purge recyblebin ，把回收站清下； 
2. delete 的表，如果表里的数据不多 的话，可以MOVE  下，MOVE 完成后，rebuild 一下IX 和PK；
3. 终极方法，exp/imp 一下，简单粗暴，测试环境中比较好的选择；

Answer 4

PURGE RECYCLEBIN测试了一下，清完后统计表空间容量（dba_data_files、dba_free_space），发现表空间剩余容量几乎没有变化，甚至还小了，已分配的块数和未分配块数没有变化。这是什么原因？对生产环境，有没有类似方法3效果的处理办法？

Answer 5

PURGE RECYCLEBIN测试了一下，清完后统计表空间容量（dba_data_files、dba_free_space），发现表空间剩余容量几乎没有变化，甚至还小了，已分配的块数和未分配块数没有变化。这是什么原因？对生产环境，有没有类似方法3效果的处理办法？purge recyclebin 后，如果没有变化，那就是回收站没有东西；生产环境的话，就建一个别的表空间，就在业务不忙的时候 MOVE 到新表空间，看你的时间，每次可以移动一部分表和LOB（如果有），并移完表后 Rebuild IX ，等所的对象都过去了，把原表空间都干掉，再把新表空间改，10g 以上表空间名可以改名；

Answer 6

delete和drop table分别造的是表和表空间的高水位问题，delete留下的空间不会从表中释放，会留给以后该表的新增数据来使用。drop掉的表的空间会留给新的extent使用，但不会从数据文件中释放高水位不释放是有道理的。
首先，表的高水位：表(段)是由盘区(extent)组成，而盘区是由一组连续的块(contiguous blocks)构成。当你delete数据的时候，它们大部分情况下会分配在不同的extent/block上，而block是逻辑存储结构的最小单位，在其中还有其他数据时是不可能简单回收的，除非打开行移动来收缩表，否则无法将这些空间从表中释放掉。
其次，表空间的高水位：当操作系统给表空间中的数据文件分配空间时，便被初始化成blocks。数据文件可以进行收缩，但仅限于未被使用的blocks。表删除以后，占用的blocks会被释放用于新的extent。但是，当连续的blocks不足以组成一个extent且不能被合并时，就形成了碎片。不能简单将它们都列为垃圾空间。表中的有效空间利用率可以通过每条记录大致占用的字节数*记录数与表中分配空间来进行估计。至于表空间的碎片情况，可以通过fsfi指数来评估。关于fsfi可以搜索一下空间整理：
表可以通过行移动来收缩，或是逻辑导出再倒入
表空间：数据逻辑导出以后，重新创建表空间，再进行导入