最近对于学习有个新的领悟，并不是所谓的技术上面的，更多知识习惯上和心路上的体会，以前每天看完oracle都腾不出时间来看看关于linux的东西，现在自己在工作中要每天抽出点时间学习linux，然后个人发觉学习要一直进行下去，如果你中途有一段时间脱离了这个状态，你再想进入就会很花时间而且很需要毅力，自己也一直再改进自己的学习方法和习惯，也希望大家能找到适合自己的高效方法！还是说一下技术的话题吧！

还是一篇pub的帖子http://www.itpub.net/thread-1519595-1-1.html

说到了一个没有数据的表却占有40G的空间，当时由于以前对于hwm和shrink move还算理解，很自然的想到了是由于之间delele删除数据，此时只是数据删除了相应的空闲extent并没有释放，方法如果是空表直接truncate重构了一个initial extent的表段是最高效的，如果是shrink space对于大表其实对于资源消耗比较大，所以一般也建议shrink在业务闲时做，pub的网友的回答说到了更多关于hwm的关系，其实hwm在表中仅仅是空闲于非空闲block的分界线，跟空闲真的没有绝对的关系，网友们提到的truncate table然后空间释放了会觉得是因为hwm导致了空闲的占用，根据truncate的原理确实会重置hwm为0，但是并不是hwm降低了将会导致了释放空闲空间，例如alter table tablename move,此时只会降低hwm，并不是释放空间，move只是重构了一模一样的表段，然后收缩数据降低了hwm，疼出的空间还是会存放在剩余的空闲的extent中。

SQL> select bytes/1024/1024,segment_name from user_segments where segment_name='TT01';

BYTES/1024/1024 SEGMENT_NAME

--------------- --------------------------------------------------------------------------------

6 TT01

SQL> alter table tt01 move;

Table altered

SQL> select bytes/1024/1024,segment_name from user_segments where segment_name='TT01';

BYTES/1024/1024 SEGMENT_NAME

--------------- --------------------------------------------------------------------------------

6 TT01

其实通过上述问题的讨论也证实了truncate的原理：重构原表段的initial 表段，然后删除原表段。同样Truncate表段时会把该buffer cache写进disk。相应的shrink和hwm等的一些要点可以参考之前个人blog

http://dotaddjj.itpub.net/post/43172/523794和http://dotaddjj.itpub.net/post/43172/523624

当然如果表段的初始initial非常大，此时即使truncate表段时，也不会缩减大部分空间，此时仅仅只是释放了多余的非初始的initial extent段，当然一般表段的initial不会达到很大，但是如果我们经常用exp和imp时，如果没有指定compress=n，默认的会把表段和索引的相应的extent压缩到一个或者几个大的extent内，这样即使truncate很有可能也打不到理想的效果，此时就需要shrink space了！shrink space会压缩表段，甚至可能会压缩到initial 表段数量级以下，相应的案例在dba3手记中杨老大有个不错的案例，可以好好读下大师作品！

[@more@]