不过作者的原意，是确定一个查看table占用space的procedure的正确性，当然不是一个普通的table，这个table里有多个blob字段。
我的回答如下
这里对dbms_space.unused_space这个procedure的实现机制不了解，不知道你这里运行完后的结果究竟是怎样的，是对还是错，这里先谈谈自己的认识。
首先，正如你提到的，你的表里含有lob字段，对于这种类型的字段来说，oracle并不是和table的segment存在一起的，而是对于每个lob的字段，都会多出两个segement一个类似于SYS_LOB0000051373C00002$$ 一个类似于SYS_IL0000051373C00002$$，分别来对于blob的segemnt和其index segment。当表被drop掉时，这两个表也是会drop的，而本身表里的记录存的是一个locator，通过其来locate到这两个segment，得到lob字段的data。这里不知道，unuse_space计算的时候会不会把这些lob的segment也算上，如果有误差可能就是这里造成的误差了。
不过看unuser_space的参数是把segement做为参数的，所以估计是没有用到这里的lob的segment的。
对于任何的表的delete操作，oracle都只会清理数据，并不会马上shrink的，毕竟shrink的消耗是很大的，这个对于生产中的delete操作，就shrink的话，是生产接受不了的，不过提供了table的shrink动作。truncate也是如此，不过truncate消除高HWM，不会shrink空间。
其实对于lob的字段来说，当delete以后也是会清理到无用的data的，不过是空间并没有压缩，如果你要压缩表的空间的同时，还想shrike这些blob的空间的话，你可以用命令
alter table yourlobtable shrink space cascade;
或者
alter table yourlobtable modify lob(lobcolumn) (shrink space);
这两个命令好像是只能10g支持哟，不过上面的命令需要先enable row movement哟。
